Closed Bug 1499500 Opened 6 years ago Closed 1 year ago

Find in page is not possible in Add-ons manager

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
112 Branch
Tracking Status
firefox64 --- wontfix
firefox65 --- wontfix
firefox112 --- fixed

People

(Reporter: yoasif, Assigned: willdurand)

References

(Blocks 1 open bug)

Details

(Keywords: access, nightly-community, parity-chrome, Whiteboard: [design-decision-approved])

Attachments

(1 file)

A use case I often encounter when using the add-ons manager is searching for an add-on I know that I have installed and disabling/enabling/using preferences for it. 

Unlike most other Firefox pages, search in page does not work.

Steps to reproduce:

1. Navigate to add-ons manager
2. Do shortcut for find in page (ctrl/cmd f)
3. Type query
4. Hit enter

What happens:

A new page opens with results that I am not interested in at the moment. 

Expected result:

A highlight (like exists in about:preferences) that shows me matching add-ons that are installed so that I can interact with them further. 

FWIW, this is how Chrome currently works - and there isn't even a link to the add-ons store in Chrome (and the "link" to the add-ons store here is somewhat obfuscated behind this search box).
Blocks: 1489296
This is working as designed, find in page applies to web content, not browser UI, and about:addons is treated as UI.
The bug suggests though that there are common uses that this design doesn't account for.  Lets get a UX opinion.
Flags: needinfo?(emanuela)
Whiteboard: ux-decision-needed
Just adding some additional feedback here - I understand that find in page applies to web content, but the "ctrl f" shortcut applies to the find in page *and* find in browser UI - eg. about:preferences or the bookmarks/history library (the one that appears as a standalone window). 

about:preferences is more relevant here and actually has the desired behavior; the find in page toolbar doesn't appear, but focus moves to the input on the page and searches in the browser UI.
See Also: → 1499514
Thank you for sharing this use case, Asif.

This is interesting. 
I believe someone using the add-ons manager should be to search on the page. This behavior is also coherent with similar views (the precedently mentioned preferences panel). 

At the same time, I think it's important to keep a clear connection with the addons website.

At the moment, I don't have an on spot solution. I'd like to keep this in our roadmap for future improvements in the add-ons manager.

Thanks aswan for NI me.
Flags: needinfo?(emanuela)
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 longer blocks: 1489296
Whiteboard: ux-decision-needed → [ux-decision-needed]
Many extensions here. I truly _detest_ Firefox not finding my add-ons. 

Alphabetical + split is too coarse, not sufficiently user-friendly for all use cases. 

Is it possible for the appearance of about:addons to be altered by an extension? Or by something in the chrome folder of a profile?
I'm so glad I found this bug, I have been losing my mind for months ever since FireFox 59 and the so called "fix" of Bug 1263313 (new-amo-search)
Change the search in add-ons manager to use just AMO search

-.-

I'm glad to see this hasn't been closed as a duplicate yet like Bug 1504396 "Can't search installed addons" https://bugzilla.mozilla.org/show_bug.cgi?id=1504396

That was closed with a 6 year old, but isn't exactly the same thing....

Anyway this can be corrected I'll be very happy.
Priority: -- → P3
Depends on: 1505924
Blocks: 1505924
No longer depends on: 1505924
Keywords: parity-chrome

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.

Depends on: 1525179

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.

Flags: needinfo?(shmediaproductions)

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)

Flags: needinfo?(mixedpuppy)

(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.

Flags: needinfo?(mixedpuppy) → needinfo?(shmediaproductions)

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.

Severity: normal → S3
Type: defect → enhancement
Flags: needinfo?(shmediaproductions)
Flags: needinfo?(mixedpuppy)
Whiteboard: [ux-decision-needed] → addons-ux
Whiteboard: addons-ux → addons-ux [design-decision-needed]

(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).

Keywords: access
Duplicate of this bug: 1815105

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 !

Assignee: nobody → wdurand
Whiteboard: addons-ux [design-decision-needed] → [design-decision-approved]
Attachment #9319250 - Attachment description: Bug 1499500 - Enable default find in about:addons. r?rpl!,mstriemer → Bug 1499500 - Enable default find in about:addons. r?rpl!,mconley!,mstriemer
Pushed by wdurand@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/17cb7647a0f5
Enable default find in about:addons. r=mstriemer,rpl,mconley
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch
Duplicate of this bug: 1718233
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: