Note, this bug may be a bit more complex than expected. The current default is false, if a user opted-out he will have: suggest.searches = false (default), userMadeSearchSuggestionsChoice = true. If we just swap the default for suggest.searches to true, a user who has previously opted-out, will end up with suggest.searches = true, userMadeSearchSuggestionsChoice = true, that is wrong. Unless we want to introduce a new pref that replaces suggest.searches, we may have to uplift a patch that mirrors the current suggest.searches value in a userSearchSuggestionsChoice pref, so that when we flip the default, we can migrate that to a user pref. Any opinions or ideas?

Hi Marco! I wanted to followup to see if you have an update on introducing a new pref. Is there a possibility for us to land this by prebeta checkin? Beta uplifts from nightly are going to be difficult so I want to explore if we can land this in nightly still.

I'm evaluating alternatives. One possibility, as Panos suggested, would be to move suggestions to a new pref. The problem is that most of our code relies on the current pref, and there's already existing documentation for support and Web articles pointing to that pref. And we also have shield studies in flight using this pref name (even if they are unlikely to run when we reach 55, so the problem may be minor). it just sounds expensive because it requires changing all the code that refers to the pref, and searching for support documents. We could clearly not fix existing support forum threads. Another possibility, could be to set the default pref value in code rather than in firefox.js, after storing the current value apart, at least for one version. Then we should investigate what will happen in various cases (downgrade/upgrade, when we'll switch default pref for real in the next version) to be sure we're not missing on something. I was suggesting an uplift because it's the safest thing to do among these. I can spend some time tomorrow into looking at this and see how the various solutions look.

(In reply to Marco Bonardo [::mak] from comment #1) > Unless we want to introduce a new pref that replaces suggest.searches, we > may have to uplift a patch that mirrors the current suggest.searches value > in a userSearchSuggestionsChoice pref, so that when we flip the default, we > can migrate that to a user pref. I'm not sure I understand -- you're saying if the user disabled suggestions, we store that info in another pref, and then when we flip suggest.searches, we also look at that other pref, and if it's true, then don't flip suggest.searches for that user? (And presumably remove that other pref too?)

(In reply to Drew Willcoxon :adw from comment #4) > I'm not sure I understand -- you're saying if the user disabled suggestions, > we store that info in another pref, and then when we flip suggest.searches, > we also look at that other pref, and if it's true, then don't flip > suggest.searches for that user? Right, when userMadeSearchSuggestionChoice is true, we should set .searchSuggestionChoice to the suggest.searches value. Then we know the user made a choice and which choice he made. On the next version, in the urlbar constructor, we would check if .searchSuggestionChoice exists, and reflect its value into the user value of suggest.searches if they differ. Additionally, update .searchSuggestionChoice with every suggest.searches change. But logistically the simplest thing to do is try to avoid the uplift requirement. So, alternatively to the uplift, we could in the urlbar constructor (pseudo-code): if (!exists(.searchSuggestionChoice)) { if (.userMadeSearchSuggestionChoice) { .searchSuggestionChoice = suggest.searches; else .searchSuggestionChoice = true; } // Survives just for this session. setDefaultPref(suggest.searches, true); if (suggest.searches != .searchSuggestionChoice) suggest.searches = .searchSuggestionChoice; Additionally, update .searchSuggestionChoice with every suggest.searches change. Unfortunately this may create problems to enteprise settings, since they can set defaultPref or lockPref in the autoconfig, and we'd surely override defaultPref here :(

I'll try make a patch for uplift, in the end that looks like the safer approach, it's 1 month to the next uplift so I assume uplifting a safe patch shouldn't be an issue.

to simplify uplift tracking, moving that work to bug 1364002

Comment on attachment 8870380 [details] Bug 1344928 - Enable search suggestions by default in the Location Bar. https://reviewboard.mozilla.org/r/141832/#review145482 Looks good to me!

Pushed by mak77@bonardo.net: https://hg.mozilla.org/integration/autoland/rev/830c06ded9bb Enable search suggestions by default in the Location Bar. r=past

Suggestions being off by default was one of the last tiny pieces where Firefox privacy was better than Chrome's. After this change, Chrome or Chromium is just as good in privacy as Firefox. With this change, I will not be able to tell people any more that Firefox takes their privacy more seriously than anyone else.

(In reply to Robert Kaiser from comment #12) > Suggestions being off by default was one of the last tiny pieces where > Firefox privacy was better than Chrome's. After this change, Chrome or > Chromium is just as good in privacy as Firefox. With this change, I will not > be able to tell people any more that Firefox takes their privacy more > seriously than anyone else. Unfortunately this is one of those cases where the reality clashes with the idealism. I won't write too much here since it's still a bug tracker and not the place to discuss this, plus I'm likely not the right person :) The opt-in didn't really work, most users don't want to make choices, and that was pretty much clear both from telemetry and from browsing the web. When we had the fixed opt-in notification (not going away until a choice was made) every tutorial or presentation video I saw on the Web had it well visible up there, nobody cared to click the simple YES/NO buttons. So we just made it go away after a few days. Still that meant most uses who could have benefited from the feature didn't get it. Privacy-caring users had various chances to interact with this in the past, I suspect most just replied NO to the old notification and that's fine, we respect that choice. Those users won't notice any difference. What about new users? Now we show a new notification with a direct link to disable the feature on FOCUS (before you even started typing anything), and it will always be possible to use the separated search bar, as well as it's possible to disable suggestions globally, or only in one of the 2 bars. After all Firefox is about choice. We also removed a bunch of cases where sending text to the search engine is likely not wanted (things looking like urls or whitelisted as local hosts through prefs are never searched for). Finally, everything is easily settable through the usual pref files (so enterprises and system builders can fix the prefs as they see fit). As many times in the past, we are just taking the path that functionally would benefit most users, while allowing the choice to take a different path to everyone. While you could disable suggestions in Chrome, it's hidden in a checkbox in advanced prefs, and there's no alternative search bar, so we are still quite better at this.

(In reply to Marco Bonardo [::mak] from comment #13) > Privacy-caring users had various chances to interact with this in the past, > I suspect most just replied NO to the old notification and that's fine, we > respect that choice. Those users won't notice any difference. I actually had them turned off and they were auto-turned-on in my Nightly, much to my surprise. So I definitely noticed a difference, and one that undermined my carefully selected privacy (even if you think Firefox shouldn't respect it by default). Thankfully I have a privacy-respecting search engine set and not Firefox' default. > While you could disable suggestions in Chrome, it's hidden in a checkbox in > advanced prefs, and there's no alternative search bar, so we are still quite > better at this. That's debatable. We are just as bad as them by default now.

(In reply to Robert Kaiser from comment #14) > I actually had them turned off and they were auto-turned-on in my Nightly, > much to my surprise. That would have happened only by upgrading nightly after more than a week. In any case with the latest bug fixes it can't just happen, when we are in doubt we always fallback to disable.

(In reply to Marco Bonardo [::mak] from comment #15) > That would have happened only by upgrading nightly after more than a week. > In any case with the latest bug fixes it can't just happen, when we are in > doubt we always fallback to disable. Good to know, thanks. I probably took a long time to update because of multiple factors, including that I use self-compiled builds and was very busy recently.

Release Note Request (optional, but appreciated) [Why is this notable]: it gives more prominence to the search features of the location bar that let users find what they want faster [Affects Firefox for Android]: no [Suggested wording]: Search suggestions are now enabled by default for users who haven't explicitly opted-out [Links (documentation, blog post, etc)]: none

Verified as fixed using Nightly 55.0a1 (Build ID: 20170605100313) on Ubuntu 16.04, Mac OS X 10.12 and Windows 10 x64.

added to 55beta release notes