New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 720293 link

Starred by 4 users
Status: Available
Owner: ----
Cc:
█ hdodda@chromium.org
nyerramilli@chromium.org
█ scottchen@chromium.org
█ msrchandra@chromium.org
█ ranjitkan@chromium.org
dpa...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression: Weird tooltip for Icon-External button is seen on md-settings.

Reported by abom...@etouch.net, May 10 2017 
Chrome Version:60.0.3095.0 (Official Build) b553e926d6cc3f7d4fa5963d0d25d2d02eacd983-refs/heads/master@{#470437}
OS: Windows(7,8,8.1,10), Linux(14.04 LTS), Mac(10.11.6, 10.12.3)

Pre-condition:
1. Sign-into chrome with valid credential.
2. Apply Deadpool fullscreen Theme using url: https://chrome.google.com/webstore/detail/deadpool-full-screen-them/echjomhoplepodjjaaohelfnlnoelhgd?hl=en-GB

What steps will reproduce the problem?
1. Launch chrome, navigate to chrome://settings/syncSetup and click&drag Icon-externals button of ‘personalise google services’, observe.
2. Navigate to chrome://settings/appearance, click&drag Icon-externals button, observe.
3. Navigate to chrome://settings/help,click&drag Icon-externals button, observe.

Actual: 
1. After step 1, Unnecessary subtext is seen or there is gap between Main text and subtext within tooltip.
2. After step 2, Chopped tittle text is seen within tooltip.
3. After step 3, Tooltip is not seen even-though Icon-Externals button link gets open to NTP.

Expected: Tooltip for Icon-Externals button should be proper.

This is regression issue, broken in ‘M 60’ and below is manual bisect info:
Good build:60.0.3080.0
Bad build:60.0.3081.6
Actual_outlink.mov
4.5 MB Download

Comment 1 by hdodda@chromium.org, May 10 2017

Cc: hdodda@chromium.org
Labels: hasbisect-per-revision
Owner: scottchen@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build: 60.0.3080.0(Revision:466837).
Bad build: 60.0.3081.6 (Revision:467177).

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

CHANGELOG 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/9cdfb9133834fee69961f61e7f8f2c2ba01d416c..c3e69c366f3e5c247276fec6c1dba93106f14ba9

From the CL above, assigning the issue to the concern owner 

@scottchen - 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.

Review-Url: https://codereview.chromium.org/2825493003

Thanks!

Comment 2 by msrchandra@chromium.org, May 10 2017

Labels: Proj-MaterialDesign-WebUI

Comment 3 by dbeam@chromium.org, May 18 2017

Labels: Hotlist-MD-Settings-General
fwiw: this is almost certainly a problem with the native tooltip rendering

Comment 4 by scottchen@chromium.org, Jun 1 2017 

It appears that when you drag an <a> element, it just puts all of the inner text into the tooltip. See: https://jsfiddle.net/9jzym85u/.

So this is not a problem specifically within Settings. I'll ask around to see if this should even be considered a native bug.

Comment 5 by scottchen@chromium.org, Jun 1 2017

Owner: ----
Status: Available (was: Assigned)
I'm not able to determine what the solution would be, so I'll let someone more knowledgeable address this.
Project Member

Comment 6 by sheriffbot@chromium.org, Jun 4 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 by dpa...@chromium.org, Jul 16

Components: -UI>Settings Blink
Per comment#4 this seems to be a generic problem, not specific to Settings.

Not sure what the correct Blink component for <a> is, so adding the generic "Blink" component for now.

Comment 8 by kochi@chromium.org, Jul 17

Components: -Blink UI Blink>HTML>A
Can anyone on browser side of tooltip layout/rendering can take a look at this?

Comment 9 by tkent@chromium.org, Jul 20

Components: -UI -Blink>HTML>A UI>Settings
In Blink point of view, this works as intended. Safari has the same behavior.

If we don't expect this link-drag behavior in the settings pages, we should add draggable=false to <a> elements.

Comment 10 by dpa...@chromium.org, Jul 24

Labels: -Pri-1 Pri-3
Status: Available (was: Untriaged)
Thanks tkent. I guess we could make some links in Settings non draggable, although I think this is a very low priority.
►

Sign in to add a comment