Closed Bug 1718233 Opened 3 years ago Closed 1 year ago

Add quick filter in Extensions page to quick search needed installed extension by it's name

Categories

(Toolkit :: Add-ons Manager, enhancement, P3)

Firefox 89
enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1499500

People

(Reporter: murznn, Unassigned)

References

Details

(Whiteboard: addons-ux)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

I have large list of installed extensions, and there is too hard to quickly find needed extension in long list, for example to change it's settings or switch it on-off.

Expected results:

Please add text input field, that will do filtering list of installed extensions by typed string. This will greatly improve usability of Extensions page!

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Product: Firefox → WebExtensions
Component: Untriaged → Add-ons Manager
Product: WebExtensions → Toolkit

Hi Jorge,
we have been discussing about this issue during our triage meeting today, and we decided that before evaluating if changing this behavior would require additional input from a ux perspective, we wanted to ask your point of view from a product perspective.

Follows some context about this (e.g. when we discussed about this in the recent past, what the current behavior is likely due to)


I recall that mstriemer and I discussed about this behavior while we were working on rewriting the about:addons UI out of XUL, but we didn't want to change it in the middle of the rewrite and so we opted to keep it (and related automated tests) unchanged.

I think we did also try to track back when the current behavior was decided and what was the rationale behind it, but we couldn't track it back (it may have been very likely something discussed and introduced long long time ago).

By taking a quick look for other about: pages in Firefox which a similar search input, I actually think that this was likely introduced to match a similar behavior we have in about:preferences, e.g. they share a couple of characteristics:

  • the search input is placed in a very similar position of the about page
  • the search input is focused on both Ctrl-F (or the shortcut key preferred for that in the current locale) and '/'

Nevertheless, the outcome of searching in the searchbox is quite different:

  • in about:preferences it does search and filter the preferences sections
  • in about:addons it opens a new tab that search for those extensions on AMO

Even with not that many extension installed in the same Firefox profile (I do have 15 included the disabled ones), I personally think that making it possible to search or filter the list of the installed extension would be useful, either from that search input or by not overriding the default keyboard shortcut to trigger the findbar (which should work just fine, especially now that the entire about:addons page is an HTML page).

Flags: needinfo?(jorge)

The current behavior is a pretty old decision. If I recall correctly, the ideal solution at the time was to show a combination of local and AMO API results, but it was deemed too complex for the resources we had then, so we decided to go with the simpler approach of opening a new tab of AMO results.

I still think it would be ideal to show both local and API results in about:addons when the user types into the search box. An alternative would be to only show local results and add a callout to search for that term on AMO, opening a new tab. We would definitely need UX help for any of these, and some planning time to determine if we need to experiment with either approach first.

Flags: needinfo?(jorge)
Severity: -- → S3
Priority: -- → P3
Severity: S3 → N/A
Whiteboard: addons-ux

Has there been any update on this? I'm not sure if my complaint merits a separate bug, but I would really appreciate if the list of extensions didn't hijack Ctrl+F and / to search for extensions on the store. That behavior is very counterintuitive, and it's frustrating that there's no other way to search for an installed extension (short of triggering the find in page box manually, if that's possible, but for me it's faster to scan manually).

As a comparison, Chrome only searches local extensions when you search at chrome://extensions. To search all extensions, you have to visit the Chrome Web Store.

It doesn't help that trying to scroll about:addons can be a migraine trigger. bug 1658601.

So users who get migraines from that scrolling behavior have to rely on search (not page down) in about:preferences, and page down (not search) in about:addons, which combination is not very intuitive or discoverable, and can require special keyboards.

Possible duplicate of bug 1705958, bug 1504396, bug 1499500, etc.

Mozregression puts the change at December 7th to 8th, 2017, but stops without completing. "Unable to find build info" and all.

Likely regressed by bug 1263313, since it shows up in the regression range and it says it's brwaking this...

I'd like to propose that:

  • searching in your local add-ons really isnt that useful
  • having a page search an api and parse the results isn't all that useful, when search more just takes you to amo

I'd like to propose that 1. searching in the add-ons page irs pretty useful, since it can be the only accessible way to navigate the page, and, 2. searching in the amo page isn't that useful since it doesn't work.

(In reply to benjamin.j.grant from comment #4)

Has there been any update on this? I'm not sure if my complaint merits a separate bug, but I would really appreciate if the list of extensions didn't hijack Ctrl+F and / to search for extensions on the store. That behavior is very counterintuitive, and it's frustrating that there's no other way to search for an installed extension (short of triggering the find in page box manually, if that's possible, but for me it's faster to scan manually).

I second this - having an addon search would be great and I'm all for it, but the hijacking Ctrl-F and / to search external extensions makes the current behavior very frustrating and, in my opinion, somewhat user-hostile. It literally makes me wonder if Mozilla has some ulterior motive in pushing me to the external extension search, but I can't come up with one. For me, there is currently no way I'm aware of to find an extension other than scrolling around - on my installation (MacOS, FF 105.0.3), the "Find in Page" option is disabled in about:extensions!

I think a reasonable behavior would be similar to what, for example, most Android app drawers do: searching in the existing box filters the existing addons, and then provides an option to search externally. If the query doesn't match any existing extensions, hitting Return in the search box will take the user to an external search.

I'm not actually sure what a Return in the case of an existing extension would do - probably open the options, I suppose?

I second this motion.

The find and quick find bar shortcuts ("Ctrl-F" and "/") have been enabled in the about:addons page as part of the changes landed as part of Bug 1499500 in Firefox 112.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1499500
Resolution: --- → DUPLICATE

The find and quick find bar shortcuts ("Ctrl-F" and "/") have been enabled

This is not a solution for this issue, because it's just a text search in all page texts, and not a filter by an extension name at all!

We need a way to filter the long list of installed extensions!

You need to log in before you can comment on or make changes to this bug.