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

Issue 802221 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 801938
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : Overlapping of grey focus highlight is seen in chrome://settings/system.

Reported by rp...@etouch.net, Jan 16 2018

Issue description

Version: 65.0.3322.3 (Official Build)Revision 8758ca55b13d4f2082b2ed9269fce8f37f37c577-refs/branch-heads/3322@{#6}(32/64-bit)
OS: Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1,10.13.3)

What steps will reproduce the problem?
1. Launch chrome,navigate to chrome://settings/system and click on 'Use Hardware acceleration when available' toggle button
2. Now move focus between 'Relaunch' button and 'Toggle button' using Tab and 'Shift + Tab' key to move focus back and forth,observe
 
Actual: Overlapping of grey focus highlight is seen when focus is seen between 'Relaunch' button and 'Toggle button'
Expected: Overlapping of grey focus highlight should not be seen between 'Relaunch' button and 'Toggle button'

This is regression issue, broken in ‘M 65’ and below is the bisect info :
Good build: 65.0.3319.0  (Revision: 528845).
Bad build: 65.0.3320.0 (Revision: 529150).

You are probably looking for a change made after 528926 (known good), but no later than 528927 (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/0e14c8fe74f35a3ce00768292531ab81fd6102fb..4f17bd28170e9cfb6b67bc1c37828ce99bc211d9

Suspect : https://chromium.googlesource.com/chromium/src/+/4f17bd28170e9cfb6b67bc1c37828ce99bc211d9

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

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

Thanks!

Note : Issue is also reproducible on Win PGO 65.0.3322.4
 
Actual_video.mov
820 KB Download
Expected_video.mov
847 KB Download

Comment 1 by dpa...@chromium.org, Jan 16 2018

@kochi: Your original CL seems to have changed the order in which styles are applied, which is the explanation behind the observed bugs.

See before screenshot, where the content/slot styling has higher precedence, setting the right margin. See after screenshot where paper-button styling has higher precedence.
before_cl.png
38.2 KB View Download
after_cl.png
39.2 KB View Download

Comment 2 by dpa...@chromium.org, Jan 17 2018

FYI the source code for this particular case is at [1]. Attempted prefixing ::slotted() to ":host ::slotted()", but that did not seem to affect the ordering of the styles.

[1] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/controls/settings_toggle_button.html?l=47

Comment 3 by kochi@chromium.org, Jan 19 2018

Status: Started (was: Assigned)

Comment 4 by kochi@chromium.org, Jan 19 2018

Mergedinto: 801938
Status: Duplicate (was: Started)
I think this should be same as  bug 801938 .

I'm wondering that as currently WebUI is using Polymer 1, which uses
Shadow DOM V0, why ::slotted() which is V1-only pseudo element is used?

Comment 5 by kochi@chromium.org, Jan 19 2018

Also I'm not sure I can tell the difference between expected and actual
video, but I guess dpapad@ sees the difference and investigated the
CSS style rule application order problem, which coincides the cause
with  bug 801939 .

If the fix for 801939 did not fix this, please dedupe and let me know.

Comment 6 by dpa...@chromium.org, Jan 19 2018

@kochi: WebUI is using slotted() as a preparation of moving to Polymer 2 (tracked by issue 738611). Polymer 1 itself is changing ::slotted() to ::content on-the-fly, which is why you see ::content in the devtools.

Comment 7 by kochi@chromium.org, Jan 22 2018

Thanks for the explanation!  That makes sense now.

Comment 8 by kochi@chromium.org, Jan 22 2018

The bug link in comment #5 should have been  bug 801938 , not 80193*9*.
Labels: ET-MUM-Reported

Sign in to add a comment