This previously depended on bug 1525179 since find in page didn't work on the HTML sub document, it might work now with some changes to update find in page to work with fission though.

Can fixing this proceed now that 1525179 has been fixed?

I just tested this and it looks like we could support find in page now. The BrowserUtils.canFindInPage() helper [1] will need to be updated, and some way of focusing the search-addons component [2] and the find in page is likely needed as well.

We'll likely want some input from the UX and/or product teams on the right way to handle this.

[1] https://searchfox.org/mozilla-central/rev/b6f52976b562008c9d9ceeda22907e1eda506c8e/toolkit/modules/BrowserUtils.jsm#83-86
[2] https://searchfox.org/mozilla-central/rev/b6f52976b562008c9d9ceeda22907e1eda506c8e/toolkit/mozapps/extensions/content/aboutaddons.js#1169-1183

I'm suggesting to use the existing search box. Rename 'Find more add-ons' to just 'Find add-ons'.

While a query is typed in to the box, filter down the extensions while highlighting the match.
Pressing 🔎/⏎ would search in AMO, as it does now.

Not sure on whether there is a need for (is the help text enough?), and how to make it more clear to the user, that you can also search in AMO.
Is replacing 🔎 with a text button of 'find more add-ons' possible? Would revising the help text (would probably call for the text box to be enlarged) make a difference?

My idea is to edit about:addons (either the global GUI, or the Recommendations tab (and possibly Extensions and Themes too)) to add a link to the https://addons.mozilla.org/ homepage, allowing users to search for new addons there. I'm surprised such a link doesn't exist yet.

Then the search box would be changed to search through either locally installed extensions/themes (depending on the selected tab), or both at the same time.

(In reply to nyanpasu64 from comment #13)

Then the search box would be changed to search through either locally installed extensions/themes (depending on the selected tab), or both at the same time.

If it's per-tab, search in other tabs, and show with a (blue bg, white text) badge the number of results in all tabs. This helps in guiding the user to what they want.

This would also be useful for users who can't scroll about:addons.

I'm also regularly affected by this. I have 30+ extensions and many hare hidden from the inteface so when I want to go to the settings of one I can't just right click it from there.

Would having a "fake result" displaying "search for XXX on addons.mozilla.org" work? With a big CTA? It would appear after the filtered results, as a way of saying "ok we can't find what you're looking for here, but let's find it there".

I have a workaround:

• Ctrl-t to open a new tab
• Ctrl-f to bring up the find bar
• Ctrl-Alt-a to open about:addons

The find bar will remain there and is usable.

BTW I have 55 addons (and I consider it not many since I had 70+ before Firefox Quantum).

If you have more than ~50 extensions installed, it can be pretty tedious to find a particular one. Some extensions don't have a browser action so their options page can only be accessed from about:addons. So it would be nice if there was a way to search for an installed addon by name.

The findbar could still be disabled on this page, since this could be implemented within the SearchAddons class. The about:preferences page has findInPage.js that supports searching strings in the page from a search field. That helps to justify disabling the findbar on about:preferences. But there isn't any comparable feature in about:addons.

My idea is that the search field would work similarly to about:preferences' search field, just highlighting text that user has typed in. But if the user hits Enter or clicks the search glass icon, then it opens an AMO search. So the search field would support finding text in page as well as searching AMO.

That's a bit of work, so an alternative could be to just allow the findbar to work as it normally does. I'm not aware of the rationale for disabling it though. (It's not just that the Accel+F key is suppressed so the page can use it to focus the search field. You can't enable the findbar by any means, e.g., the menubar or the app menu.) I suppose there's a technical reason for this that precludes enabling the chrome findbar, so a find-in-page feature might be more easily implemented in aboutaddons.html.

Keep in mind this disabling of find-in-page only pertains to about:preferences and about:addons. All other system pages allow the use of the findbar. So the only other example is about:preferences, which does permit finding in page. It has its own pretty sophisticated find-in-page system. So if the findbar should be disabled on about:addons because it's disabled on about:preferences, then it makes sense for about:addons to implement a system similar to findInPage.js.

Likely regressed by bug 1263313.

The rationale was that "I think we can remove the functionality that isn't much value and point search add-ons straight at AMO" even though not everyone can scroll the list and some users may need an accessible and functional alternative.

Related to bug 1584111.

Shane, can you reach out to UX/PM about if we should remove the ctrl+f and / shortcuts to focus the AMO search and instead have them open the find in page?

There are links in comment 11 about how to get started fixing this, if that's a decision we're okay with.

Comment 17 has an interesting workaround to get an about:addons with the findbar open. (Ctrl+T, Ctrl+F, Ctrl+Shift+A)

(In reply to Mark Striemer [:mstriemer] from comment #21)

Shane, can you reach out to UX/PM about if we should remove the ctrl+f and / shortcuts to focus the AMO search and instead have them open the find in page?

Sure, though I'm not sure who to contact.

There are links in comment 11 about how to get started fixing this, if that's a decision we're okay with.

Comment 17 has an interesting workaround to get an about:addons with the findbar open. (Ctrl+T, Ctrl+F, Ctrl+Shift+A)

I wasn't able to use or find any info about the Ctrl+Shift+A hotkey, maybe that's platform specific or something? But it does work to open a new tab, open the findbar for that browser, and then navigate that browser to about:addons. That is, navigating to about:addons doesn't close any active findbar, and the findbar works as normal. So it does seem like the hotkey and canFindInPage are the only obstacles to enabling normal use of the findbar.

(In reply to lilydjwg from comment #17)

I have a workaround:

• Ctrl-t to open a new tab
• Ctrl-f to bring up the find bar
• Ctrl-Alt-a to open about:addons

The find bar will remain there and is usable.

BTW I have 55 addons (and I consider it not many since I had 70+ before Firefox Quantum).

Thanks for the workaround though the CTRL+ALT+A doesn’t work here.

If only at least there were a switch in about:config to enable the findbar in about:addons.

Other workaround: open about:addons and click the 'Find' toolbar button (available in Customize mode if you don't see it).

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

I'm pretty sure I'm the Shane that Mark was asking.

It's kind of unfortunate that we overloaded that and didn't do in-page search. I'll mark it to ask ux about.

This idea has also been posted on Mozilla Connect: https://connect.mozilla.org/t5/ideas/allow-me-to-search-my-own-add-ons/idi-p/20823

(In reply to David Durst [:ddurst] from comment #4)

I would prefer to WONTFIX this, at least while this is a XUL page, and note
that all extensions are listed in alphabetical order.

The enabled ones at the top are in alphabetical order, and the disabled ones
at the bottom are also in alphabetical order.

No one answered this so I thought I would. I have 80+ enabled add-ons, and many more disabled (but still useful from time to time). Going through the whole list searching for (e.g.) "something related to search" is painful:

• Hopefully the name contains "search", but not necessarily at the beginning, rendering the alphabetical sorting moot. (Installation/activation/last use date would be more meaningful for me)
• A whimsical or historical name might obscure what the add-on is actually about.
• Many add-ons have multiple, loosely related features; you won't necessarily guess them from the name.

Searching by name in the page would certainly reduce the pain, but it'd be much better to be able to search the descriptions (like the search in addons.mozilla.org does). Ideally it'd search even the preferences and release notes, similarly to how search works in about:preferences (or in the Settings app in iOS).

Please assign this bug, the add-on page is difficult to use if you manage over 20 addons.
Also would be nice to have a link to addon author and addon application page without needing to go deeper than the addons page.

But at least let us you ctrl+f without having to do the new tab trick !

https://hg.mozilla.org/mozilla-central/rev/17cb7647a0f5