Issue 870658 link

Starred by 2 users

Issue metadata

Status:	Assigned
Owner:	bettes@chromium.org
Cc:	pbos@chromium.org █ tbergquist@chromium.org nyerramilli@chromium.org rbasuvula@chromium.org markchang@chromium.org
Components:	UI>Browser>Bubbles UI>Browser>Omnibox
EstimatedDays:	----
NextAction:	----
OS:	Windows , Mac
Pri:	2
Type:	Bug-Regression
hasbisect-per-revision FoundIn-69 FoundIn-70 RegressedIn-69 Target-70 M-70 ET-MUM-Reported Group-Omnibox proj-desktopui Hotlist-DesktopUITriaged

Regression:Service handler icon is not seen in omnibox after user clicks outside the bubble

Reported by vineetha...@etouch.net, Aug 3

Issue description

Chrome Version: 70.0.3510.2 (Official Build) Revision 19bbe7b51081dd5aca29d10d5f881cce7eb95ff8-refs/branch-heads/3510@{#4}(32/64 bit)
OS: Windows(7,8,8.1,10), Mac(10.12.6 ,10.13.1 ,10.13.6 ,10.14)

What steps will reproduce the problem?
(1) Launch Chrome, navigate to www.gmail.com and sign in with valid credentials.
(2) Click on the service handler icon present on the RHS of the omnibox to open the bubble.
(3) Now click anywhere outside the bubble and observe.

Actual Result  : Service handler icon is not seen in omnibox after user clicks outside the bubble.
Expected Result: Service handler icon should remain in omnibox even after user clicks outside the bubble.

This is regression issue broken in ‘M-69’ and providing the bisect using per-revision bisect,
Good build: 69.0.3489.0(Revision: 574446)
Bad build : 69.0.3491.0(Revision: 575129)

You are probably looking for a change made after 575111(known good), but no later than 575112(first known bad).

CHANGE-LOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+log/c4ceae97969eeba83784bc86221a3ad6fc7feff8..754f9b669fd1200644b11820597926099b60d4b3

Suspect: https://chromium.googlesource.com/chromium/src/+/754f9b669fd1200644b11820597926099b60d4b3

@tbergquist: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Issue is also reproducible on latest Canary build #70.0.3511.0

Thank You!

	ActualVideo.mp4 952 KB View Download

	ExpectedVideo.mp4 1.2 MB View Download

Comment 1 by tbergquist@chromium.org, Aug 3

Yep, this is definitely the right revision to finger for the regression - sorry!  I'll be back with a fix.

Comment 2 by tbergquist@chromium.org, Aug 6

Cc: markchang@chromium.org pbos@chromium.org tbergquist@chromium.org
Owner: markchang@chromium.org

Talked offline with markchang@ and pbos@, summarizing here:
Impact is not too big, and risk is nontrivial since we don't have great test coverage over some of this stuff => not reverting this for 69.

We'd instead like to roll forward and change this UI, possibly/probably for 70.  Neither expected nor actual are really great flows: the difference between deny vs. ignore vs. clicking outside the dialog is not obvious, and using a radio button group to select between these options doesn't actually make sense either - they should be buttons.

Comment 3 by markchang@chromium.org, Aug 6

Labels: -Pri-1 -M-69 -Target-69 Pri-2
Owner: bettes@chromium.org

reassigning to bettes for UI guidance.

Alan, please click on the handler icon in GMail in the omnibox. The text is suboptimal, especially as we are using 3 states with radio buttons, and have two action buttons. It is unclear, IMO.

https://screenshot.googleplex.com/Dg8eQMiOXyB

Can you please work with Shimi for some text updates as well?

Comment 4 by markchang@chromium.org, Aug 6

Labels: proj-desktopui

Comment 5 by tbergquist@chromium.org, Aug 7

There's a different UI that solves more or less the exact same problem - it still registers a protocol handler, but it pops up proactively instead of being summoned by a click to the handler icon.  pbos@ and I like its approach much better (see attached screenshot).