No Way To Remove One-Off Searches From Address Bar Only When Separate Search Bar Is In Use
Categories
(Firefox :: Address Bar, enhancement)
Tracking
()
People
(Reporter: anowack, Unassigned)
Details
(Keywords: blocked-ux)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
Update to Firefox 77 with the separate search bar is in use and having previously used browser.urlbar.oneOffSearches to remove one-off seraches from the address bar.
Actual results:
Followed instructions in Release Notes to use uncheck search engines on the about:preferences#search page. Search engines were removed from the one-off searches in the address bar as desired, but also from the one-off search engines available in the search bar, which was not desired.
Expected results:
Some method to remove one-off searches from the address bar but not the search bar should be provided. browser.urlbar.oneOffSearches allowed this previously, but only as an all-or-nothing option.
Allowing separate lists of one-off searches to be enabled for the two separate bars would allow maximum flexibility for the user. Alternately a preference or about:config option could an all-or-nothing choice like browser.urlbar.oneOffSearches did, but only when the separate search bar is enabled.
|
Reporter | |
Comment 1•4 years ago
|
||
Either one-off buttons are useful to the user or they are not, we think they are useful to most by default, and we provide a way to hide them if the user doesn't want them.
One-off buttons are extremely useful to me, but only from the search bar where I want to perform searches. My goal in configuring the search and address bars is total separation of search and navigation functionality. This makes the address bar one-off buttons useless to me, and a possible privacy risk in the admittedly unlikely event I accidentally select them.
In another comment on that bug it was implied that not driving users to unsupported userchrome was a goal; that is currently the only option to hide the buttons from the address while still allowing one-off searches from the search bar.
|
||
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 3•4 years ago
|
||
While this isn't producing anywhere near the reaction of more controversial changes, in addition to the comments on Bug 1628926, see here for other requests for this functionality:
https://old.reddit.com/r/firefox/comments/givqz8/hiding_one_off_search_from_url_bar/
https://old.reddit.com/r/firefox/comments/gv9007/browserurlbaroneoffsearches_preference_has_been/
https://old.reddit.com/r/FirefoxCSS/comments/gvfi4c/how_to_remove_search_engine_suggestions_from_url/
There are userChrome workarounds that have presented, but besides being unsupported, those are problematic because they can't stop keyboard navigation from selecting the invisible one-off buttons.
|
||
Updated•4 years ago
|
I'd love to see this done, too.
It's very annoying, I keep getting to the searches via keyboard, without wanting to.
Therefore the "workaround" is not really that, not for me anyway.
Please, can we get the old setting back? It was at least working.
I'd also like to have the ability back to disable the one-off search bar completely.
The userchrome.css hack is a hack in its worst meaning.
|
|
||
Comment 6•4 years ago
|
||
(In reply to klk745 from comment #5)
I'd also like to have the ability back to disable the one-off search bar completely.
The userchrome.css hack is a hack in its worst meaning.
Are you also accidentally executing searches, or do you have a different use-case that this is breaking?
|
|
||
Updated•4 years ago
|
I would also really like to see this fixed.
or do you have a different use-case that this is breaking?
My use-case, with all due respect, is that I use the separate search bar.
So I unambiguously want to execute searches only from the search bar, and only use the URL bar for typing in URLs.
The forced display of the "This time search with:" at the bottom of the URL bar effectively mocks the users who prefer the separate search bar, by turning the URL bar back into the 'URL+search' bar, which is exactly what such users didn't want when they opted for the separate search bar.
Apart from the mockery, it is a significant visual clutter. The "This time search with:" thing occupies significant space, often around 40% of the total height of the results pane.
It is just silly that this behaviour applies when the separate search bar is in use.
I would stress that even further, but in the current political climate I'm actually frightened that in such circumstances you simply decide to ditch the separate search bar instead.
We are currently forced to use the CSS workaround that applies display: none !important to that bar, or roll back to v76.
I am hiding it with CSS.
It does not work very well, there are phantom items now in the results menu, they are not visible, but when navigating with the keyboard, I have to scroll through them.
I would really like to see the browser.urlbar.oneOffSearches flag working again like it did before v77.
|
|
||
Comment 8•4 years ago
|
||
I discussed the issue with the User Experience team, the decision is that for now we don't feel the need to split the behavior across the two bars.
The urlbar can be used as a search bar, we plan to improve that behavior in bug 1644572, and then it will also provide additional utilities that may be good in general, and not just for search.
We want to address the "accidental disclosure to search engines" problem as part of bug 1644572, if that should not yet be satisfying please file a bug after the fact.
|
|
Reporter | |
Comment 9•4 years ago
|
||
The urlbar can be used as a search bar,
The entire point of having a separate search bar is to not use the urlbar as a search bar, but I am not surprised by the WONTFIX regardless. I don't suppose a feature request to have the keyboard navigation skip the one-off buttons if they are hidden by userChrome would go anywhere either, since userChrome is unsupported?
|
|
||
Comment 10•4 years ago
|
||
Yes, unfortunately userChrome can do anything so it's hard to "support" it. Bug 1644572 should change one-off buttons to not directly make a search, so privacy hits should be reduced. Of course invisible selection won't be great, but keeping one offs visible at that point will most be a visual annoyance rather than a risk, and maybe you'll find new filtering options useful. We're also looking into reducing the one-off padding in compact mode, in case part of the problem is one-off taking too much space.
I understand it's not a satisfactory answer, but that's where we are right now. Keep up with the feedback, while we can't satisfy every request, we discuss users feedback weekly.
|
||
Comment 11•4 years ago
|
||
For vacation reasons I didn't see the needinfo until now and though you removed the tag and set the bug to WONTFIX, I can only emphasize what gserg.g posted. It describes exactly the bad user experience this created for me as well.
Description
•