User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

With Firefox 76, we can:

• Type in the address bar about:config and press Enter (ignore the warning)
• Type in the search bar and look for these preferences: browser.urlbar.openViewOnFocus
  browser.urlbar.update1
  browser.urlbar.update1.interventions
  browser.urlbar.update1.searchTips
• and set its value to false

Then close and restart Firefox.

Actual results:

With Firefox 77, this does not work.
What is the solution?

Expected results:

URL bar expanding must be disabled.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

There is no solution, because the current behavior is the expected one. Feature preferences are used to do soft release of new features and design, and are always removed once the feature shipped in a release.
You can ask in https://www.reddit.com/r/FirefoxCSS/ for unofficial and unsupported solutions.

@code: for disabling expansion of focused location bar with top sites prefill use browser.urlbar.suggest.topsites=false (see bug 1627858), regarding focus overlap see bug 1627861.

Marco: out of curiosity, are there telemetry stats of usage of those "megabar-mitigating" prefs from time period they worked? They surely were marginal enough to remove them and proceed to release, but I'm curious how those stats looked and how strong signal would have been needed to prevent shipping.

(In reply to Michal Čaplygin [:myf] from comment #4)

Marco: out of curiosity, are there telemetry stats of usage of those "megabar-mitigating" prefs from time period they worked?

We don't telemetry feature prefs status, because those prefs are fated to go away as soon as a feature is released, we prefer to measure engagement with the urlbar (how and how much it is used).

(In reply to Marco Bonardo [:mak] from comment #5)

We don't telemetry feature prefs status, because those prefs are fated to go away as soon as a feature is released [...]

Thanks for information, it is valuable and TBH very surprising insight for me; I thought that's what is the purpose of those prefs and their (supposed) telemetry: to provide data for decision making during feature introduction. So is that so apart from written subjective feedback scattered around interwebs you have no objective metric how much nightly/aurora users really tend to adapt or not adapt to such newly introduced changes and ideas?

[...] we prefer to measure engagement with the urlbar (how and how much it is used)

See? In this case users cannot just stop using urlbar to signal they don't like certain change in it.

I cannot believe such changes are designed by committee and approved from the table with no "hard data" to refer to.

(In reply to Michal Čaplygin [:myf] from comment #6)

Thanks for information, it is valuable and TBH very surprising insight for me; I thought that's what is the purpose of those prefs and their (supposed) telemetry:

No, feature prefs are only used in a few cases:

1. we release the feature, something critical (like navigating pages) breaks, we can easily disable the feature flipping a couple prefs
2. we want to release the feature to a subset of the population and then slowly enlarge its reach (Webrender is being releases like that for example)
3. we want to maintain a feature in Nightly/Beta, but not Release, to collect more feedback before reaching the largest population

Once the feature is in Release and there have not been major criticalities, the prefs and the old code are removed. Why using prefs? Mostly for development speed, an alternative system not exposed to users is possible and much wanted, but it's expensive to setup, while prefs just work, and they are available now. about:config is showing a no-warranty sign, for good purpose.

users really tend to adapt or not adapt to such newly introduced changes and ideas?

First, changes are studied by multiple persons in the UX and Product team and iterated over and over, until ready for development, then presented to the Eng team, that further provides feedback and may start new iterations to refine the change.
Then user studies are ran on the implementation before releasing the feature, through actual user studies and experiments on a randomized part of the users population. Multiple studies and eperiments may be done. In the meanwhile features are tested in Nightly, and then Beta.
Only when all of this data is analyzed and confirmed, and changes have been made based on it, the prefs are flipped for Release.
After release what happens is mostly:

1. telemetry is used to evaluate if engagement changed somehow, this also includes user retention
2. feedback is collected through various channels (communities, bug reports...), reported to the team and discussed weekly with UX and Product
3. changes are made based on the collected feedback and data