In bug 1344924 we added a contextual tip about search suggestions (yay!) but we run into a problem with the new oboarding tour because the search suggestion hint auto-expands when the address bar is focused. This causes the tip to overlap the onboarding icon (bug 1374496). I discussion this with Peter Dolansjske and we decided the best experience would be to keep the tip but only show it when text is entered in the address bar. This will leave the tip visible to a user who begins to type in the address bar and potentially, when the user views the onboarding search tour.

There is a very compelling reason to show the tip on focus, that is privacy-related, we want it to be visible before the user starts typing anything. I don't think we want to sacrifice privacy for the onboarding experience, since privacy is one of our main goals.

(In reply to Marco Bonardo [::mak] from comment #1) > There is a very compelling reason to show the tip on focus, that is > privacy-related, we want it to be visible before the user starts typing > anything. > I don't think we want to sacrifice privacy for the onboarding experience, > since privacy is one of our main goals. The desire to effectively communicate that search suggestions send your entered text to a third party makes sense. I just don't think the current design of the tip actually achieves this. It just talks about search suggestions (as a feature) and the UIPref does the same. Unless I'm missing something you'd need to go into the privacy policy to see the details of what's happening. Is it that we are trying to educate users on the privacy risk or is it that we are trying to give users, that already understand the privacy implications, a quicker way to change the setting before typing?

(In reply to Peter Dolanjski [:pdol] from comment #2) > The desire to effectively communicate that search suggestions send your > entered text to a third party makes sense. I just don't think the current > design of the tip actually achieves this. This is something that should be brought up with UX and product managers (Javaun) (and maybe discussed with legal?), it was just implemented according to the specs that were agreed upon. > Is it that we are trying to educate users on the privacy risk or is it that > we are trying to give users, that already understand the privacy > implications, a quicker way to change the setting before typing? My understanding is: 1. educate users about the possibility to search and get suggestions from the location bar 2. allow a quick way out for users who want more privacy (through the settings link) Note that for this week both Javaun and Panos are on PTO, and I can't take official decisions here, nor giving you details about legal discussions that happened, since I don't know all the details (I cannot even access the legal bug). I'm merely reporting my understanding of the situation. So we would likely be frozen until someone can give you those additional details (likely next week) :( For the UX part, you can refer to Phlsa (though someone else created the text in the notification and I don't remember the name atm).

(In reply to Marco Bonardo [::mak] from comment #3) > Note that for this week both Javaun and Panos are on PTO, and I can't take > official decisions here, nor giving you details about legal discussions that > happened, since I don't know all the details (I cannot even access the legal > bug). I'm merely reporting my understanding of the situation. So we would > likely be frozen until someone can give you those additional details (likely > next week) :( > > For the UX part, you can refer to Phlsa (though someone else created the > text in the notification and I don't remember the name atm). Thanks Marco. No problem. We'll follow-up with Javaun/Philipp.

Summoning Phlsa, Shorlander, and Wselman. This is the only in-product UI we've created to tell users about the new unified bar capability. So whatever we do let's be judicious and decisive ;-) Shorlander did first mockup of the UI. Philipp worked on it as well. It does not display indefinitely, it's coded to display 4 times, and we know in some edge cases it only does it 2-3. I'm actually more worried about losing visibility of the prompt than any other reason. We've seen in studies Bill has presented that some users (crude ballpark of 20%) look at their hands when they type. I worry that they'd miss the prompt if it only appeared when they start typing. We've also done a bunch of UR studies (user testing, eyetracking, etc.) the UR/UX folks may know if those studies suggested anything about visibility of the prompt.

@verdi @phlsa, perhaps you guys can decide on the best approach? There are certainly multiple options if we're primarily concerned about visibility.

I had a conversation with shorlander about this today. To alleviate the immediate issue, we could only show the search tip when the user focuses/clicks the search bar. I would also include clicking into it even when it is already focused on new tab here. Pro: Fixes the overlap issue and might have a better view rate since the tip is shown when the users' attention is already in that area Con: Some users might not see it. We actually considered this in the original design (I think Marco brought it up), but ultimately decided against it. That was before the new onboarding though, so it probably makes sense to revisit. In a more general sense, we are running into the issue of competing messages again. https://cl.ly/1T1i2a2T3y3w There's a lot of competition here, but that is beyond the scope of this bug.

(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #7) > I had a conversation with shorlander about this today. > > To alleviate the immediate issue, we could only show the search tip when the > user focuses/clicks the search bar. I would also include clicking into it > even when it is already focused on new tab here. This sounds good to me! +1

We need to fix this for 57 (on boarding dependency)

Changing the bug description, since this is about focusing the bar, not typing. The main change to the current behavior is that the hint currently also shows when opening a new tab or window (when the URL bar is focused automatically).

If I get comment 7 correctly we want: - always show on mouse focus - always show on keyboard focus - show on click even if already focused - not show on code focus I'm not sure I can distinguish CTRL/CMD+L from the code setting the focus on new tab opening, but I can try.

(In reply to Marco Bonardo [::mak] from comment #11) > If I get comment 7 correctly we want: > > - always show on mouse focus > - always show on keyboard focus > - show on click even if already focused > - not show on code focus That sounds right!

Comment on attachment 8903155 [details] Bug 1384050 - Search suggestion contextual hint should only be shown when a user manually focuses the URL bar. https://reviewboard.mozilla.org/r/174938/#review181044 Looks good based on the previous discussions. I looked at the code but I haven't re-tested the patch. ::: browser/base/content/urlbarBindings.xml:1511 (Diff revision 1) > if (this.getAttribute("pageproxystate") != "valid") { > UpdatePopupNotificationsVisibility(); > } > > - // We show the opt-out notification on every kind of focus to the urlbar > - // included opening a new tab, but we want to enforce at least one > + // We show the opt-out notification when the mouse/keyboard focus the > + // urlbar, but in any casse we want to enforce at least one typo ::: browser/base/content/urlbarBindings.xml:1519 (Diff revision 1) > if (whichNotification == "opt-out" && > this._showSearchSuggestionNotificationOnMouseFocus === undefined) { > this._showSearchSuggestionNotificationOnMouseFocus = true; > } > > - // Check whether the focus change came from a user mouse action. > + // Check whether the focus change came from a keyword/mouse action. keyboard

There's a timeout in the test when I EventUtils.synthesizeMouseAtCenter(gURLBar, {}); The screenshot looks good though, apart from the system notifications https://public-artifacts.taskcluster.net/W2mBOzrcTx6B0xbCH8p73g/0/public/test_info/mozilla-test-fail-screenshot_uNmDW3.png Not yet sure what may be causing the intermittent failure yet :(

using mousedown and inputfield seems to solve the failure, at least from the retriggers I did...

Pushed by mak77@bonardo.net: https://hg.mozilla.org/integration/autoland/rev/3cc38c1489e4 Search suggestion contextual hint should only be shown when a user manually focuses the URL bar. r=Paolo