47 bytes, text/x-phabricator-request
|Details | Review|
This pref completely disabled the Address Bar, it is synced across devices through Sync, and in general makes so that we don't open the panel nor run any kind of search, the user can type in the input field and visit urls or search (depending on what URIFixup decides).
So let's recap a bit. We have 2 set of prefs: A. browser.urlbar.autocomplete.enabled: this basically controls whether the popup is shown at all. It is only exposed in about:config, but it is Synced. B. browser.urlbar.suggest.*: these allow to filter matches (bookmarks, history, tabs, searches...) and are exposed from Preferences, but they are not Synced. We have 2 possible paths here: 1. keep things as they are: the advantage is that autocomplete.enabled is synced across all the devices. The disadvantage is that mobile and desktop devices are VERY different and also have very different address bars, and as such the pref syncing may be more annoying that useful. I may want to disable autocomplete on dekstop but not on mobile. Another disadvantage is that autocomplete.enabled is not exposed in preferences, only the suggest* prefs are, thus it looks like a footgun. If the pref is inadvertently set (maybe even by Sync) the Address Bar may appear broken. To workaround this we basically linked the prefs, so when autocomplete.enabled is set to false, all the suggest.* prefs are set to false as well. Viceversa if any suggest.* pref is set to true, autocomplete.enabled is also set to true (and synced to other devices!). 2. Remove all of this complication. Stop supporting autocomplete.enabled, sync suggest.* prefs across devices. Only desktop uses those prefs so mobile will continue using autocomplete.enabled. The Address Bar will be basically always enabled, but the user can filter out certain results from Preferences. The downside is that I'm sure we have a (maybe vocal) minority of users that don't want to get the Address Bar popup. It could be workarounded hiding the panel through a userchrome.css hack. 3. Keep both, but unlink prefs. The advantage is that users willing to completely disable the popup still can and we sync that across devices. The disadvantage is that the prefs footgun is still there: if enabled is false the urlbar will appear broken even if the preferences are checked. We could maybe grey out the prefs in that case, though it wouldn't be clear WHY they are greyed out. I'd like to collect your feedback and thoughts about this.
I must stand corrected, suggest.* prefs ARE synced.
My personal opinion is that we should remove autocomplete.enabled, and users that really don't want to see the popup can hide it through css. The use-cases are minor (I think someone just dislikes our pre-selected first entry when all the suggest options are disabled). In general I don't see advantages into syncing autocomplete.enabled across desktop/mobile devices, so we could well drop it and leave it to mobile.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Yeah, I think I agree we should remove autocomplete.enabled. I don't think we should support disabling one of the most prominent features of the app -- of any web browser, really. At least, we shouldn't have it but not really support it. But as I say I'm not sure we should have it at all. I'm guessing it's been around for a long long time, back when the urlbar was a really simple autocomplete popup? OK, maybe allowing that to be disabled was OK, but not anymore.
we reached consensus with Verdi about this change, morphing bug.
Summary: Support browser.urlbar.autocomplete.enabled at the controller level → Remove support for browser.urlbar.autocomplete.enabled
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/0efe75dd8ff4 Remove support for browser.urlbar.autocomplete.enabled. r=adw
Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
You need to log in before you can comment on or make changes to this bug.