1644972 - Stop exposing browser.urlbar.disableExtendForTests pref to users

Status: RESOLVED FIXED

(Firefox :: Address Bar, task, P2)

Description

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

disableExtendForTests pref is being used in the wild to disable the urlbar expansion, but it is a footgun, because it actually breaks the urlbar visualization, making the results pane unusable. At that point one can only set maxRichResults to 0 and get no results at all.

While this may be a welcome change by someone, we've seen multiple users whose browser was broken after they followed these advices, and then were unable to revert and go back having a working urlbar, without a profile reset.

This pref was only created for the sake of simple disabling in perf tests, not for actually using the urlbar, in the future it may break more things. We should replace it with just setting a property or invoking a method in the head file.
Alternatively we could use prefersReducedMotion in the tests, but since they are perf tests, that could mean not measuring newly added animations on tab open that could indeed cause slowdowns.

Comment 1

[Troy Janda]

Closing the loop-hole to disable the expansion of the urlbar. I am thinking it would be easier to simply create a pref to stop the expansion for those that do not like it. Simple switch that would please both those that like the new urlbar and those who don't.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I'm not sure if you are implying we do this to disallow users from disabling the expansion. That's just wrong, we do this because users broke their browsers after using an hidden preference that was intended for tests. And then they reach to us to ask for help.
We already added a switch in bug 1629303, so there'd be no point in keeping this dangerous setting.

Comment 3

[Steven Penny]

Marco, I think the (valid) point Troy is trying to make is this:

People are reaching for "disableExtendForTests", and essentially anything else
they can find to stop the address bar from getting larger. To be clear, I am not
talking about the drop down list of website, but the address bar itself getting
larger.

The fact that people are willing to break their browser, intentionally or
otherwise, should tell you that this change is deeply unpopular. But instead of
recognizing that obvious fact, and offering a method to disable and/or return
the address bar to its previous behavior, you instead seem interested in
torpedoing anything that could even possibly be used to that end.

If an option was added to restore the previous address bar, then the bug on this
page would be irrelevant, because people wouldnt bother with little known
options like "disableExtendForTests" when they could just use
"restoreAddressbarSize" or whatever it would be called.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Steven Penny from comment #3)

People are reaching for "disableExtendForTests", and essentially anything else
they can find to stop the address bar from getting larger.

There's already the ui.prefersReducedMotion pref and userChrome. How many workarounds do we need? This one is also broken, while the other ones work.

The fact that people are willing to break their browser, intentionally or
otherwise, should tell you that this change is deeply unpopular.

That doesn't tell us anything about how many users like/dislike it. I've seen this "I broke my browser" problem being reported 2 times in 4 months. Is that a lot? And that's also why this is not yet fixed, it's not an extremely high priority, but users with a broken browser is something we must avoid at any cost. Footgun prefs have been removed in general from Firefox for the last 12 years based on these assumptions, this doesn't make an exception. It is not providing any user benefit that can't be achieved differently, on the contrary it breaks the browser.

Comment 5

[Steven Penny]

There's already the ui.prefersReducedMotion pref and userChrome.

Just to be absolutely clear, for anyone visiting this page,
"ui.prefersReducedMotion" DOES NOT stop the expansion in all cases. It will
stop expansion when focused with F6 or by opening a new tab, but expansion will
still happen when the dropdown is displayed. To stop expansion when the
dropdown is displayed, seems is currently only possible via CSS hacks:

https://www.userchrome.org/megabar-styling-firefox-address-bar.html#enlargement

How many workarounds do we need?

Only one, as long as its a complete solution. Please let me know when that
happens.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Steven Penny from comment #5)

It will stop expansion when focused with F6 or by opening a new tab, but expansion will
still happen when the dropdown is displayed.

Yes, and currently we don't plan to limit the extension when the results panel is open because, after evaluating a ton of feedback, we didn't identify obvious problems with that, apart from subjective taste. When the panel opens a much larger ui change and movement is already happening, regardless of the extension being present or not.
I must note that almost all the browsers on the market, a bunch of famous Web and Desktop apps are doing that; if it would be a widespread or severe problem, even for a small group, it would be a lot more obvious and reported. The only uncommon thing in Firefox is that we extend also the input field on focus, and ui.prefersReducedMotion addresses that.
I must also note that setting browser.urlbar.maxRichResults to 0 prevents the results pane from opening at all. I really discourage from using it though, the urlbar provides a lot of useful features that get lost that way.

Comment 7

[Troy Janda]

I must note that almost all the browsers on the market, a bunch of famous Web and Desktop apps are doing that

There are a lot of people that dislike this reading the thru comments on bugzilla and Reddit. Most people I have talked to the overwhelming options are negative. This is the problem with Firefox as of late, you guys are following what everyone else is doing and not leading. Your losing touch or just ignoring your user feedback. IF you don't want people finding ways to break the browser to disable some feature, then stop making everything absolute, a simple solution would have been to make an option/pref to disable it all together for this instead of working to close/remove workarounds in an effort to force feed this. ui.prefersReducedMotion does not completely revert the url bar back to what it was pre FF 75, in my case it does help, but I have to go further and set browser.urlbar.maxRichResults to 0 to get the desired effect, and as you state I lose out on other search related functions.

In my opinion the focus should not be the URLBAR it should be the content, the customization, and addons.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Troy, I appreciate your passion, but I disagree with what you wrote. I can explain you the reasons, but this is not the place, Bugzilla is a technical bug tracker yet, not a place to discuss Mozilla's merits and demerits.
If you want to discuss, you can reach the team on Matrix, where we're available every day in the Firefox Desktop Community channel. You won't get a different answer related to this, but maybe someone can help clarifying your doubts related to the Firefox leadership.

Comment 9

[Dão Gottwald [:dao]]

Attachment: Bug 1644972 - Restrict browser.urlbar.disableExtendForTests to tests and remove it from tests that don't need it. r=mak

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/10d626f2709c
Restrict browser.urlbar.disableExtendForTests to tests and remove it from tests that don't need it. r=mak

Comment 11

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/10d626f2709c