1418024 - API to access search bar from a web extension is missing in Firefox 57+

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, enhancement, P5)

Description

[Lennart Kruse]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

I wrote a new web extension to migrate https://github.com/gmaslov/clear-search-2/blob/master/src/main/chrome/content/ClearSearch2.js to Firefox 57 and searched https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API for any API to access (and subsequently clear) the search bar's content.


Actual results:

There is no such API yet
(as confirmed on https://stackoverflow.com/a/47301254/3890673)


Expected results:

There should be such an API, as there is one to access menus, tabs, and so on

Comment 1

[Andrew Swan [:aswan]]

I'm not sure how useful this is given that the search box is hidden by default beginning in 57

Comment 2

[Lennart Kruse]

I'd suggest considering a discussion about the usefulness hiding the search bar in the first place as "off topic" here, as it is highly emotional. As long as there is a search box, it deserves an API such as every other element of interest for an extension has (or does). We all want as many extensions to be ported as possible.

Comment 3

[Martin]

I personally tried to live for couple of days without search bar and hit the wall every day dozens of times. I search very often for namespaces and classes, e.g. "System.String". Which ends up with "page not found" when typed into URL bar of course. Also I need to open new tab manually every time I'm going to search for something new - but as Lennart said, not/having a separate search bar is off topic here.
Long story short - I've used mentioned extension for years and it is definitely one I miss the most after upgrading to FF 57. Doubt very much I'm alone.

Comment 4

[YF (Yang)]

(In reply to Lennart Kruse from comment #2)
> I'd suggest considering a discussion about the usefulness hiding the search
> bar in the first place as "off topic" here, as it is highly emotional. As
> long as there is a search box, it deserves an API such as every other
> element of interest for an extension has (or does). We all want as many
> extensions to be ported as possible.

This conclusion is questionable as Mozilla does not seem to intend to support all modifications for all elements.

Comment 5

[u603070]

This can also be easily implemented as a FF setting: "Clear search box following search." This should cater to the majority of use cases.

Comment 6

[Lennart Kruse]

As Andrew stated: The search box is hidden by default. So adding a setting as zaharon suggests would either cause confusion ("What search box?") or has to be enabled/disabled depending on the search box' state.

Plus: Yes, that'd cover *my use case*. But that's just that, a use case. Don't get me wrong, I'd be happy to have such a preference. But I don't know what extension might be out there that cannot be ported due to the missing API of the current search box... so while a preference would cover my use case, it would not fix the bug.

Comment 7

[Caitlin Neiman [:caitmuenster]]

Hi Lennart, this has been added to the agenda for the WebExtensions APIs triage on May 15. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1Y_oYPldTT_kQOOouyJbC-8y3ASIizScLKFRhQfsDQWI/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 8

[Lennart Kruse]

Hi Caitlin; sure, I can do that. I'd love to join via IRC though, which should be possible according to the wiki? Thanks

Comment 9

[Caitlin Neiman [:caitmuenster]]

Sure thing! We'll look for your in the channel.

Comment 10

[Caitlin Neiman [:caitmuenster]]

This was denied in the triage meeting; Luca to follow up with more details about the decision and suggestions for filing an enhancement request.

Comment 11

[Luca Greco [:rpl] [:luca] [:lgreco]]

We've discussed about this request during the last WebExtensions API triage, and we agreed to deny the request for a new "search bar" specific API.

The main reasons behind this decision are:

- we don't currently provide any WebExtension APIs to directly intercept and look into the search requests from the user, e.g. currently for the "location bar" we only allow extensions to provide more search results using the omnibox API), and so if we would ever provide an API for the "search" bar which is separate from the omnibox API, it would likely follow the same design (and so without allowing the API to see the results, but only adding more sources for search results provided by the extension)  

- the search box is currently not visible by default, and it may be even possible that is going away completely in future Firefox versions, which makes a new "search bar" specific API not a very compelling feature

- "clearing the search bar after searching" part of this issue looks more like a fix for the current behavior of the "search bar" Firefox UI than an actual extension API (as also comment 5 mention).

We understand that "clearing the search bar after searching" could be a reasonable request, but we are not convinced that it is a WebExtensions API on its own, it sounds more reasonable as a new proposed behavior, or as an about:config / about:preference setting that the user may choose to toggle to change the current behavior in the proposed one.

And so, we are denying the 'new "search bar" API' request, but we want also suggest the reporter to file the "clearing the search results" part of this issue as a separate Firefox feature request (the following link point to the right Product and Component inside bugzilla: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Search), the team that works on those components is in a better position to evaluate if it is a request that they may accept.

If that feature is accepted, implemented and exposed as a Firefox preference, then it could be reasonable to evaluate to expose it (just the preference) to the extensions as part of the browserSettings API.

Comment 12

[Brett Zamir]

If someone will post or has posted a bug for the enhancement to the Firefox UI to clear after searching, please cross-link here... I'd very much be interested in that... I can go ahead and file if no one else has or is planning to...

Comment 13

[Lennart Kruse]

I did not nor do I currently plan to do. As I reported this bug, I'd say: Go ahead :) and thanks.

Comment 14

[Brett Zamir]

Thanks for reporting back! Filed as bug 1462562 ...

Comment 16

[Worcester12345]

There is an older extension called "context search", which worked very well. There is one final bug holding it up from being updated, and that bug is currently being worked on. I think there was some discussion about it on "github". Good luck.

Comment 17

[Patrick Storz]

Is this still open for discussion? I just realized how much I miss the extensions "Searchbox Sync" [1] and for this extension to be implemented as a webextension, we'd need an API to interface with the search box (and/or omnibox) as suggested in this bug.

Basically we'd need one function that allows to set the searchbox text from a webextension.

[1] https://github.com/legege/searchboxsync

Comment 18

[Worcester12345]

Ditto "Context Search". Have not seen that functionality in a while. Could have used it 15 minutes ago.

Comment 19

[Patrick Storz]

Asking the other way around: If this API were to be developed by a volunteer contributor, would there be a reasonable chance of it getting accepted?

I'm annoyed daily by how limiting Firefox Quantum is in regards of search features (and by how limited it became in regards of extensions being able to help in that regard).

Having a trivial API to get and set the content of the search box would have a dramatic effect on extension development and would not only open the door for many great new extensions, but would also benefit a lot of existing extensions.