I don't think we ever meant to keep this pref around for so long. iirc we only used it as a feature gate. There doesn't seem to be a bug on file for this already.

Thank you for closing my bug report #1628365 in this case.
Well, how can we disable the annoying OneOffSearch dropdown box then?
People don't want to have this popping up in their face every time. When I want to use a different search engine, I use the separate seach bar to the right and so do many others.
An address bar is meant for entering addresses, not for constant alternative search engine proposals that can't be disabled.

And even if you remove browser.urlbar.oneOffSearches completely, you can still trigger bug #1628365 when you uncheck all one-click search engines in about:preferences#search (see comment #1 there), so the bug is definitely still there in any case.

To clarify: bug #1628365 still exists with browser.urlbar.oneOffSearches set to true and all one-click search engines in about:preferences#search being unchecked.

I cannot reproduce your problem, there seems to be some problem with the list of engines in your profile.
Could you please enable Chrome debugging from Firefox DevTools options, then open the Browser Console (ctrl+shift+j) and evaluate this:
(await Services.search.getVisibleEngines()).map(e => e.name)
post here the returned value.
Also please post the value of the browser.search.hiddenOneOffs preference from about:config.

I should also ask if you any rules in userChrome.css since those can easily cause visual bugs.

Attached you can find a screenshot showing the problem including the config settings.
It might not look very disturbing, but I disabled my bookmarks toolbar for privacy reasons.
When enabled the grey line basically creates a roof above the bookmark icons.

The only entry I have in my userChrome.css is this one:

/* https://support.mozilla.org/en-US/questions/1264286 */
#urlbar-results { display: none !important; }

When I remove it, the bug gets even worse: I then see a white space with a height of about 5px all over the screen instead of the grey line.

Thanks, but I still don't understand, there should be a visible panel there, so apparently you are using some userChrome.css hacks, that are not officially supported. And that line also seems to come from the old design, that makes me think you disabled the new design?
Could you please clarify that?

Thats what I get in the console:

(await Services.search.getVisibleEngines()).map(e => e.name)
(!) ReferenceError: Services is not defined

Am I missing s.th.?

probably your are executing it in the Web Console, not the Browser Console, they are different tools with different privileges.

Though, at this point I suspect your problem is about using the old urlbar design with that userChrome rule...

It still looks broken due to some unexpected setting in your profile. That white thing is the results pane, first of all you likely set browser.urlbar.update1 to false, but I still can't tell why that panel is empty. Try in a new profile and you'll see what I mean...

Ah, yes, I set browser.urlbar.update1 to false since the "adressbar size pumping" introduced in FF75 is pretty annoying, too.
If you're think I'm alone with that negative perception and fix, do a Google search for "browser.urlbar.update1" limited to the last week only and prepare to see 300+ results where exactly this animation is being brought up as nuisance and recommend as fix.
I don't want to sound negative, but Mozilla definitely has a knack to introducing annoying features just for "progress" over things that weren't broken at all.

And I indeed used the Web Console by mistake, but contrary to the screenshot below my Browser Console doesn't have a command line:
https://media.prod.mdn.mozit.cloud/attachments/2013/08/09/5855/76ecde685f5c9657ca47cda2dc0ba206/browser-console-commandline.png

Ok, I'm sorry to disappoint you, but unfortunately your configuration is not officially supported and the bug you have is likely caused by those unsupported changes to the profile. In normal conditions there's no bug with unchecking all the one off buttons to hide them.
You'll have to hide that grey like with another userChrome.css hack.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e51b15035afbd9717d61963a55fbfe4d870c9ce7

Release Note Request (optional, but appreciated)
[Why is this notable]: The checkbox in about:preferences#search is undiscoverable and unlabeled, users who disabled one-offs through the pref may be confused about how they can hide those and revert to unsupported userChrome instead.
[Affects Firefox for Android]: no
[Suggested wording]: The browser.urlbar.oneOffSearches preference has been removed. To hide one-off search buttons uncheck search engines on the about:preferences#search page
[Links (documentation, blog post, etc)]:

Backed out changeset 0c8a5b5094b6 (bug 1628926) for Eslint failure on UrlbarView.jsm

Backout revision https://hg.mozilla.org/integration/autoland/rev/c052b4aa27fadd3e3cc19f43706881feecdb5240

Failed push https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=297817865&resultStatus=testfailed%2Cbusted%2Cexception&revision=0c8a5b5094b63c14c331f0cdec7c25c92b229300

Failure log https://treeherder.mozilla.org/logviewer.html#?job_id=297817865&repo=autoland

Drew can you please take a look?

Fixed, thanks

https://hg.mozilla.org/mozilla-central/rev/6c66abef1f54

Hi,
I was using the removed pref and now I have some issue using search at all.
At start, I want to clarify that I use separate search bar.
Because of this I do not want any search engines in URL bar because I have a separate bar for this.
As for now, search engines are present both in URL bar and in Search bar.

I tried to remove all search engines from the about:preferences#search
This lead to removal of search engines from the URL bar (which is good).
However, they were removed from the Search bar ass well.

My question is,
What are my options to recreate behavior of the removed pref: remove search engines from the URL bar and leave them in the Search bar?

As before, there's not a supported way to hide them [edit: without also hiding them in the search bar], but this userChrome.css rule works for me:

.urlbarView > .search-one-offs { display: none !important; }

That will hide the buttons in the urlbar view but not the search bar. It's not perfect though because you can still cycle through them with the keyboard.

Thank you for the suggestion.
Still, I'm a bit confused regarding "not supported" statement. There was a pref that control the mentioned behavior, so there was a way control it.
I appreciate that there is a userChrome way of hiding it.
A whole idea seams like another step in the bigger schema to remove search bar due to the fact that its functionality steadily moved to URL bar.

The pref only existed so that we could develop the urlbar search buttons during the regular Firefox release process without actually enabling them on release during that time. When development was done, we enabled the pref, and at some point we should have removed it but didn't. So removing the pref doesn't indicate anything about plans to remove the search bar.

Verified on Windows 10 64bit, MacOS 10.14, and Ubuntu 18.04 64bit
Using Firefox Release 76.0.1 (issue still visible on this one) , Firefox Nightly 78.0a1 (fixed), and Firefox Beta 77.0b4 (fixed)

This is in the draft notes for 77.

Hello,

The browser.urlbar.oneOffSearches preference has been removed. To hide one-off search buttons uncheck search engines on the about:preferences#search page

The wording seems wrong. It suggests that the about:preferences setting does the same thing as the pref. It doesn't. The pref removed these buttons from the address bar. The setting removes them from the search bar too. In the end, this is another case where removing a pref seems like an implementation detail for FF developers, but results in feature loss for users. This pref has been there for four years and it's quite rude to say "Oh, we never intended to give you this feature. Say goodbye to it" after we've been using it for four years.

It is a valid use case that a user wants to conduct their searches from the search bar, and consider search UI in the urlbar as visual clutter. Please support this use case.

The search bar is a legacy widget that long term we would like to remove, but we first need a good and privacy-aware replacement experience. Because of that, we don't think it's worth splitting the behavior between the urlbar and the search bar.
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.

You probably want to remove search bar because it is built with old code that may be almost duplicated with address bar code, right? If so, could search bar be reimplemented using (almost) the same code as address bar but configured to only do searches, so most of the code could be shared between them?

This is just my idea, I don't know how exactly are address and search bar implemented and if sharing code between them would be beneficial. I don't use separate search bar, but some users do so it might be useful to keep it.

Yes, potentially it could be driven by the urlbar code. It all depends on whether we can find a good way to keep separation of concerns in the urlbar, there is still a long way to go with experiments and studies.

Filip, thank you for that suggestion - as a consistent user of the search bar who also appreciates the work happening in the address bar, I am all for maintainability but prefer the separate UI for search. Appreciate the care for this experience.

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.

I filed Bug 1643185 to request an enhancement to allow separate configuration of the one-off searches in the address and search bars.

I already answered you in the other bug, please don't post advocacy comments into this technical bug tracker.