This is a regression issue, broken in M-65 series, Using the per-revision bisect providing the bisect results,

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).

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/0e14c8fe74f35a3ce00768292531ab81fd6102fb..4f17bd28170e9cfb6b67bc1c37828ce99bc211d9

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

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.

Note: Issue is also observed on Mac(10.12.6,10.13.1,10.13.3) and Linux(14.04 LTS) OS.

Thank You!

Hmm, <select>-<option> change might affect, but basically my change
is about changing its internal representation from Shadow DOM V0 to V1,
and it shouldn't change whether horizontal scroll bar is shown or not.

But for some reason, it might have affected some rendering code to
calculate the width of the <select> or the <option> element slightly wider,
and caused the setting UI dialog to show horizontal scroll bar.
In that case, someone responsible for the UI can adjust the container
width, or applying overflow-x CSS property in the container, or whatever.

Can anyone in settings UI team take a look at this?

The problem seems to be fixed by removing the -webkit-padding-end from [1].


[1] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/languages_page/add_languages_dialog.html?l=16

CL at https://chromium-review.googlesource.com/c/chromium/src/+/867946.

@kochi: Even the the CL posted above fixes the issue, see related finding at https://bugs.chromium.org/p/chromium/issues/detail?id=802221#c1.

It seems that the original change has affected the ordering of styles being applied, when it involves slot/content tags, even for V0?

Re comment#4

I think I figured it out.

It looks like for <div slot=body scrollable class=can-scroll> element,
2 rules are competing, the one is

[slot=body] {
  -webkit-padding-end: 0 !important;
}

and the other is

:host ::content> [slot=body]
{
  padding: 12px 16px;
}

For that element, the latter should have applied, but with the ToT Blink,
the former is applied, so removing the "-webkit-padding-end: 0 !important;"
rule made it fixed.

The reason why the applied rule changes is that Blink switches cascading order
comparison strategy once V1 shadow root is used, and the switch is one-way
(i.e. only V0 strategy -> V1 strategy, not the other way).
When V0 strategy is used, the latter is applied, but now with V1 strategy,
the former is applied.


We used to have elements with V0 UA shadows, but unintentionally turning
UA shadows to V1 made that strategy switch happen, so almost always 
it forced "V1 cascade order" mode.

That would break for most of websites that expect V0 cascade order,
without explicitly using V1 shadows, because Blink forces V1 cascade order.

So the fix would be not switching to V1 mode for V1 UA shadow.

It looks M65 branch is already cut, I'll submit the fix and will merge to M65.

Further investigation revealed that this happens only when

(1) you make some UA-shadow element (e.g. <option>) in another document
(2) move (e.g. appendChild() or importNode()) the element to the current
document only with V0 shadow root

and in settings web ui case, <option> was actually moved and caused the
cascade order switch.

Fix CL under review:
https://chromium-review.googlesource.com/c/chromium/src/+/875585

 Issue 802221  has been merged into this issue.

@kochi, thank you for following up with this!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c773e5725d02c7a1cf9291a33360a5fb0a17cbe2

commit c773e5725d02c7a1cf9291a33360a5fb0a17cbe2
Author: Takayoshi Kochi <kochi@chromium.org>
Date: Sat Jan 20 03:17:29 2018

Do not switch to V1 cascade order if shadow root is UA shadow

Once V1 shadow root is attached to a document, we switch
cascading order to V1-compliant mode from V0-legacy mode,
but recent migration of UA shadows from V0 to V1 caused
the cascading order switch without explicitly creating
author V1 shadow root.

This happens only in the following scenario:
1. An element with V1 UA shadow is created in another document
2. The element with V1 UA shadow is adopted to the document.

In other cases, internal APIs such as EnsureUserAgentShadowRoot()
or CreateUserAgentShadowRoot() does not share the same code path
for web-facing Element.attachShadow(), the cascading order is not
affected.

Bug:  801938 ,  787717 
Change-Id: I93e41e8f6f0acda4f3804e1ef316da205454b62f
Reviewed-on: https://chromium-review.googlesource.com/875585
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Takayoshi Kochi <kochi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530738}
[modify] https://crrev.com/c773e5725d02c7a1cf9291a33360a5fb0a17cbe2/third_party/WebKit/LayoutTests/shadow-dom/css-cascade-upgrade-from-v0-to-v1.html
[modify] https://crrev.com/c773e5725d02c7a1cf9291a33360a5fb0a17cbe2/third_party/WebKit/Source/core/dom/TreeScopeAdopter.cpp

@dpapad thanks, your analysis, especially the screenshots in issue
802221 helped me understand the problem.  This bug was my fault.

aiman.ansari@etouch.net, could you verify the problem is fixed on canary?

Once this is verified, I'll request a merge to M65.

Update : 
Retested above issue on Windows(7,8,8.1,10), Linux(14.04 LTS), Mac(10.12.6), (10.13.1) & (10.13.2) OS using latest Canary #66.0.3328.0 and issue is fixed. Now, Unwanted scroll-bar is not seen on Add Languages overlay. Kindly review an attached screen-cast.

Thank you!

Deleted: Current_Result.mp4 1.0 MB

	Current_Result.mp4 1.0 MB View Download

siman.ansari@ thanks for verifying!

Requesting Merge to M65.

This has been verified, and the fix
https://chromium.googlesource.com/chromium/src.git/+/c773e5725d02c7a1cf9291a33360a5fb0a17cbe2
contains a test case to make sure the same regression won't happen.

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Pls merge your change to M65 branch 3325 before 1:00 PM PT today, Tuesday (01/23/18) so we can pick it up for dev release tomorrow. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b72f6df15e00d0d0846936a9b9fd1b1f6b235f46

commit b72f6df15e00d0d0846936a9b9fd1b1f6b235f46
Author: Takayoshi Kochi <kochi@chromium.org>
Date: Tue Jan 23 13:47:14 2018

Do not switch to V1 cascade order if shadow root is UA shadow

Once V1 shadow root is attached to a document, we switch
cascading order to V1-compliant mode from V0-legacy mode,
but recent migration of UA shadows from V0 to V1 caused
the cascading order switch without explicitly creating
author V1 shadow root.

This happens only in the following scenario:
1. An element with V1 UA shadow is created in another document
2. The element with V1 UA shadow is adopted to the document.

In other cases, internal APIs such as EnsureUserAgentShadowRoot()
or CreateUserAgentShadowRoot() does not share the same code path
for web-facing Element.attachShadow(), the cascading order is not
affected.

TBR=kochi@chromium.org

(cherry picked from commit c773e5725d02c7a1cf9291a33360a5fb0a17cbe2)

Bug:  801938 ,  787717 
Change-Id: I93e41e8f6f0acda4f3804e1ef316da205454b62f
Reviewed-on: https://chromium-review.googlesource.com/875585
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Takayoshi Kochi <kochi@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#530738}
Reviewed-on: https://chromium-review.googlesource.com/881123
Reviewed-by: Takayoshi Kochi <kochi@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#28}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/b72f6df15e00d0d0846936a9b9fd1b1f6b235f46/third_party/WebKit/LayoutTests/shadow-dom/css-cascade-upgrade-from-v0-to-v1.html
[modify] https://crrev.com/b72f6df15e00d0d0846936a9b9fd1b1f6b235f46/third_party/WebKit/Source/core/dom/TreeScopeAdopter.cpp