Skip to content

feat(GlFilteredSearchSuggestion): Remove BDropdownItem dependency

Miguel Rinconrequested to merge
mrincon-refactor-search-suggestions into main

What does this MR do?

This change migrates the GlFilteredSearchSuggestion so it doesn't depend on the deprecated GlDropdownItem component which in turn depends on BDropdownItem.

This change reduces the surface area of the component by keeping only a small part of its API: the value that it emits via @suggestion and the icon it shows via the iconName prop.

Additionally, by removing the .native modifier in the listener support for Vue 3 is improved. See https://v3-migration.vuejs.org/breaking-changes/v-on-native-modifier-removed

BREAKING CHANGE: Support for the following inherited props/attributes are removed:

  • avatarUrl
  • iconColor
  • iconRightAriaLabel
  • iconRightName
  • isChecked
  • isCheckItem
  • isCheckCentered
  • secondaryText
  • role

The filtered search suggestions are now rendered in a <button> tag, not a link <a href="#">, so your automated tests may need updates to account for this.

Technical Notes

Why now? While working on gitlab-org/gitlab#554214 (closed) I found that the @mousedown.native.prevent listener to select a suggestion was not being captured correctly. Instead of trying to find workarounds to make the event work, I found it more valuable to migrate away from VueBoostrap for this component and leave only the event I need (without the .native modifier, which also improves our Vue 3 compatibility!).

Why not switch to GlDisclosureDropdownItem? The parent component: GlFilteredSearchSuggestionList, is not implemented by a GlDisclosureDropdown so forcing our suggestions to be disclosure items does not add much value. Yes, they behave similar to a dropdown, but we don't need the complexity.

Why keep gl-dropdown-item, dropdown-item and other classes...? Removing them can bring some side effects around their placement that I don't want to address here. Those classes are referred by other styles that's I'd have to trace so it would grow the scope of this MR too much.

Breaking changes: GlFilteredSearchSuggestion is used heavily in gitlab-org/gitlab, however, I found no instances of usages of its inherited props. So I find this breaking change is safe.

Screenshots or screen recordings

Appearance stays the same

http://localhost:9001/?path=/story/base-filtered-search--default
image

A Cypress run

I run a manual check to quickly see the appearance and interactions of the search bar are not affected:
2025-07-30_10.29.41

A manual test in Safari

Cypress cannot run in Safari, and when we introduced the .native modifier it was to address issues in Safari, so I ran some manual point and click tests in Safari:
2025-07-30_10.53.19

Integrations

Note: I don't need integration tests besides gitlab-org/gitlab, our other projects don't make use of GlFilteredSearch.

Does this MR meet the acceptance criteria?

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for conformity with the project's guidelines, security and accessibility.

Toggle the acceptance checklist

Conformity

  • The “What does this MR do?” section in the MR description is filled out, explaining the reasons for and scope of the proposed changes, per “Say why not just what”.
    • For example, if the MR is focused on usage guidelines, addressing accessibility challenges could be added in a separate MR.
  • Relevant label(s) are applied to the MR.
  • The MR is added to a milestone.
  • Added the ~"component:*" label(s) if applicable.

Components

Documentation

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • Security reports checked/validated by a reviewer from the AppSec team

Accessibility

If this MR adds or modifies a component, take a few moments to review the following:

  • All actions and functionality can be done with a keyboard.
  • Links, buttons, and controls have a visible focus state.
  • All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label for icons that have meaning or perform actions.
  • Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false" to aria-expanded="true" when an accordion is expanded.
  • Color combinations have sufficient contrast.
Edited by Miguel Rincon

Merge request reports