1627989 - Remove the browser.urlbar.openViewOnFocus pref

Status: RESOLVED FIXED

(Firefox :: Address Bar, task, P2)

Description

[Dão Gottwald [:dao]]

This is an internal pref that has lost its purpose now that we've enabled it by default in release. Bug 1627858 has been filed for a user-visible pref for the top sites feature.

Comment 1

[Chasingafterghosts]

User hostile attempt to prevent advanced users from reverting recent changes to the URL bar on their own personal browsers through about:config.

Please mark WONTFIX with prejudice.

Comment 2

[marczellm]

Where is the feedback form to request that this preference be kept?

Comment 3

[marczellm]

Is there a way to PAY Mozilla to listen to me?

Comment 4

[rghtbrn]

(In reply to Dão Gottwald [::dao] from comment #0)

This is an internal pref that has lost its purpose now that we've enabled it by default in release. Bug 1627858 has been filed for a user-visible pref for the top sites feature.

This is not true. This pref enables the user to disable the browser drop down on focus.

This option can enable better privacy and gives users a choice on when they want a drop down list to appear.

The pref should not be removed as it is still a valid feature. If anything this pref should have a user facing toggle in Options > Privacy and Security > Address Bar.

Mark as WONTFIX.

Comment 5

[swleefers]

Suggestion: remove this preference only after the new preference as per the first comment has been implemented.

Comment 6

[Patrick Pfeifer]

I fail to understand, how this could ever be set to enabled by default. Who would want this? Please keep the flag.

Comment 7

[Patrick Pfeifer]

Also, there is a comment here on another issue, that seems to suggest that a flag like this one will be added. This confuses me a little now as I thought that this is already that flag, which they are looking for https://bugzilla.mozilla.org/show_bug.cgi?id=1629303#c1 . I must be missing something.

Comment 8

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

The one removed here is an implementation flag, we use them when we develop features to disable them in case they break the release. Once a feature is released with no breakage, these prefs are removed. These are prefs only for an implementation detail, they were never intended to be user prefs.
bug 1627858 is the one to add a user pref.

Comment 9

[Patrick Pfeifer]

Thank you for the explanation, @Marco Bonardo.

If I understand it correctly, then technically there is no difference between an "implementation flag" and a "user pref". Or is there? I also fail to see any obvious naming-scheme, or "-flag", "user." prefixes or suffixes or the like that would distinguish them based on their name.

Thus if my assumption is correct, then I suggest that this "implementation flag" would simply not be removed and henceforth be used as a "user pref", as suggested in the bug 1627858.

Or is it, that it has to be deleted and then re-created in order to conform to some formal process definition?

Comment 10

[marczellm]

my understanding is that this implementation flag is a switch between old implementation and new implementation, while the user pref will control some aspect of the new implementation, but it will never behave completely identical to the old one.

Comment 11

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

(In reply to marczellm from comment #10)

my understanding is that this implementation flag is a switch between old implementation and new implementation, while the user pref will control some aspect of the new implementation, but it will never behave completely identical to the old one.

that's right.

(In reply to Patrick Pfeifer from comment #9)

If I understand it correctly, then technically there is no difference between an "implementation flag" and a "user pref". Or is there? I also fail to see any obvious naming-scheme, or "-flag", "user." prefixes or suffixes or the like that would distinguish them based on their name.

It would be pointless, the main problem is that due to technical restrictions we must use prefs, and users will discover which prefs we use anyway. We're working in a transparent environment, anyone can read bugs, patches and the code.

Comment 12

[Patrick Pfeifer]

Why would the possibility that the new behavior matches the old one be excluded from the solution space before the search for the new behavior has even started ?

Comment 13

[Patrick Pfeifer]

Apart from this, the (my, likely some other user's ...) desired new behavior seems obviously be to match the old behavior.

Comment 14

[danmattera1]

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

....These are prefs only for an implementation detail, they were never intended to be user prefs.

While I understand this was it's original purpose, what it is the downside (from a development/support) perspective to keeping this particular flag alive?

Removing the likes of browser.urlbar.update1 makes sense because if you didn't it means that you, the developers/support team, have to continue working on both the old code and the new but from what it seems (to me, at least) is that this particular flag just suppresses certain features of the new code rather than reverting back to anything from the previous code base?

Comment 15

[Harry Twyford]

I'll remove this once bug 1627858 has landed.

Comment 16

[Troy Janda]

(In reply to Patrick Pfeifer from comment #7)

Also, there is a comment here on another issue, that seems to suggest that a flag like this one will be added. This confuses me a little now as I thought that this is already that flag, which they are looking for https://bugzilla.mozilla.org/show_bug.cgi?id=1629303#c1 . I must be missing something.

browser.urlbar.openViewOnFocus set to false was suggested to me from Marco Bonardo in my bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1629303 I now see that this will be removed in an upcoming release, why make the suggestion and then take the option away. although not a fix in itself setting browser.urlbar.openViewOnFocus to false and using CSS (userchrome) to disable the expanding/shrinking helps to a degree.

Comment 17

[Harry Twyford]

(In reply to Troy Janda from comment #16)

why make the suggestion and then take the option away.

As per comment 15, this pref will not be removed until we introduce a similar user-facing pref in about:preferences. We are adding a new pref in about:preferences instead of keeping this pref because this one also controls the address bar's "retained results" feature, which we do not intend to support a pref for. Retained results is the behaviour where if you type a query without hitting Enter, then unfocus the address bar, then refocus it, the results you were previously viewing re-open.

Comment 18

[Harry Twyford]

Bug 1627858 should be done next sprint, meaning we can remove this pref after.

Comment 19

[Harry Twyford]

Attachment: Bug 1627989 - Remove the browser.urlbar.openViewOnFocus pref. r?dao

Depends on D76246

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/039d58aba1f0
Remove the browser.urlbar.openViewOnFocus pref. r=dao

Comment 21

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/039d58aba1f0