First run "You can search from here with Google" bubble prevents omnibox text entry |
||||||||||||||||||
Issue descriptionVersion: 54.0.2840.34 OS: 10.11 What steps will reproduce the problem? (1) Launch Chrome with an empty user-data-dir (2) Click the Chrome app icon in the dock to make it the active app (3) Cmd-T to create a new tab What is the expected output? I should be able to start typing a URL or search term. What do you see instead? My typing does not appear in the omnibox. At this point in the first run sequence a bubble appears with the message, "You can search from here with Google". This bubble has keyboard focus so all typing gets swallowed by it. However the omnibox has a focus ring, which implies that it has focus and is ready to accept typing. The bubble offers no obvious method of dismissing it. Pressing Escape is a convention that Chrome has created with it's non-standard UI - it's not known to a first-time user. Overall this makes for an awkward first experience with the browser. Ideally if I start typing the bubble will disappear, but there should also be a control I can click to explicitly dismiss the bubble. The behavior of this dialog, its layout, and its text should all be rethought.
,
Oct 25 2016
Yes, I think it could be. I will investigate. Regarding strings: I think very few people understand what a "URL" is. This string could be improved alongside the work on the omnibox placeholder text: https://docs.google.com/document/d/1UWYgsbvhlAF3-JSPwsCDDVq7KIEr1xxCsq81qqIqCVQ/edit. +rachelis
,
Oct 25 2016
,
Oct 25 2016
,
Nov 1 2016
Assigning to Max per #2.
,
Dec 1 2016
,
Dec 29 2016
Migrating to more generic platform label, so that it can be applied to other platforms (i.e. I love the idea).
,
Apr 5 2017
While we're awaiting UX's redesign, we need to fix the problem with this bubble. When it's visible the omnibox has a focus ring which communicates to the user that the omnibox is waiting to accept typing, however anything you type gets eaten by the bubble. This particular bubble should be changed to dismiss when the user types (and to pass that typing along to the omnibox). ellyjones@ - can you assign to someone? Maybe a good bug for patricialor@?
,
Apr 5 2017
Attaching a screen recording (captured on Canary 59). - Currently, the focus is set to the popover (bubble), i.e. the prompt cursor in the omnibox disappears as soon as the popover opens, which seems related to the issue. - Fix options might be 1) Remove the focus ring from the omnibox since the focus is on the popover, 2) Move the focus back to the omnibox, and, when the user starts typing, dismiss the popover, IMO. - If we do 2), we also need to consider how to access this popover (and popovers in general going forward) using screenreader or keyboard. - Side note re: c1 - the new proposal on the popover focus, i.e. popover shouldn't still focus, is scoped to be discussed and addressed as part of Harmony V2. There're cases to think through to assess whether the change is worth. The keyboard and screenreader accessibility issue mentioned above should be taken into consideration.
,
Apr 5 2017
We should do 2), because there should be minimum friction to getting started (i.e. with 1) you have to click in the omnibox to dismiss the dialog). I'm not sure how that affects screen readers but we should take them into account.
,
Apr 5 2017
c10 re: screen reader issue - crbug.com/696266
,
Apr 6 2017
patti, can you take a peek? :)
,
Jun 20 2017
I know I've seen some changelists go by that affect the search engine bubble. Is this bug (which mentions a few different issues in the thread, more than just the summary) still relevant?
,
Jun 20 2017
It is, and it drives me crazy. The bug pops up whenever you launch Chrome with a new profile, which I do a lot of the time for testing.
,
Jun 21 2017
,
Jun 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/96db21c3f062509bb04eb8b2c505acf96326eb36 commit 96db21c3f062509bb04eb8b2c505acf96326eb36 Author: shrike <shrike@chromium.org> Date: Wed Jun 21 01:44:06 2017 [Mac] Dismiss the first run bubble when the user starts typing. The "You can search from here with Google" first run bubble is a child window of the browser window, and is made key because it contains a button (so you can press the button via accessibility). All of this is fine, except the omnibox is the browser window's first responder and displays a focus ring. So, to the user it looks like they can start typing (and indeed, the bubble invites them to "Type to search or enter a URL to navigate...."), but the bubble consumes all key events. This is a jarring experience for a first-time Chrome Mac user. This cl changes the first run bubble to dismiss itself when the user starts typing. R=avi@chromium.org BUG= 657592 Review-Url: https://codereview.chromium.org/2951013002 Cr-Commit-Position: refs/heads/master@{#481073} [modify] https://crrev.com/96db21c3f062509bb04eb8b2c505acf96326eb36/chrome/browser/ui/cocoa/first_run_bubble_controller.h [modify] https://crrev.com/96db21c3f062509bb04eb8b2c505acf96326eb36/chrome/browser/ui/cocoa/first_run_bubble_controller.mm
,
Jun 21 2017
,
Jun 27 2017
Tested the issue on Mac 10.12.5 using chrome version 61.0.3141.0 with the below steps 1.Launch Chrome with an empty user-data-dir 2.Open new tab and start typing in omnibox 3.Observed first run bubble dismissed when start typing Please find the attached screen cast for the same. Adding TE-Verified labels. Thanks, |
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by ainslie@chromium.org
, Oct 20 2016