Issue metadata
Sign in to add a comment
|
Regression: Unable to scroll through "Main menu" options of Google News
Reported by
khushal....@etouch.net,
Jun 25 2018
|
||||||||||||||||||||||
Issue descriptionChrome Version : 69.0.3472.0 (Official Build) Revision c98da5eedd07a2e61d1a982bb9dab46e437946cf-refs/branch-heads/3472@{#1} (32/64-bit) OS: Windows (7, 8, 8.1, 10), Mac (10.12.6, 10.13.1, 10.13.5, 10.13.6) & Linux (14.04 LTS) Test URL: https://news.google.com/?taa=1&hl=en-IN&gl=IN&ceid=IN:en Steps to reproduce: (1) Launch chrome and navigate to above URL. (2) Now try to scroll up/down the "Main menu" options and Observe. Actual Result: Unable to scroll through "Main menu" options of Google News. Expected Result: Should be able to scroll through "Main menu" options of Google News. This is a Regression issue broken in 'M-69' and providing the bisect info below: Good Build: 69.0.3451.0 (Revision: 564769) Bad Build: 69.0.3452.0 (Revision: 565143) You are probably looking for a change made after 564825 (known good), but no later than 564826 (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/2045134020610ddc664eb41700d2f8b959b192c4..4f8f44f272473dfd92257e18dbe86fdf48d61884 Suspect: https://chromium.googlesource.com/chromium/src/+/4f8f44f272473dfd92257e18dbe86fdf48d61884 @rego: 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 seen on M-69 Dev (build #69.0.3464.0). Kindly refer attached screen cast. Thank You..!!
,
Jun 25 2018
,
Jun 25 2018
I guess the problem is the "c-wiz" element that has "contain: layout style". If you remove "contain: layout" from it the scrollbar appears again. I'm not completely sure what's the element with "overflow: auto" or "overflow: scroll" that is showing the scrollbar, but if a descendant has "contain: layout" its overflowing contents do not affect the parent element. So the current behavior seems the one defined in the spec. This change was intended to follow the spec for "contain: layout" (https://drafts.csswg.org/css-contain/#containment-layout): "If the contents of the element overflow the element, they must be treated as ink overflow." DevTools had a similar issue #851422 that has been already fixed. Could we ask site owners to get this fixed (for example using "contain: style" instead of "contain: layout style")?
,
Jun 28 2018
Filed internal bug with relevant team, issue 110946935.
,
Jul 5
The NextAction date has arrived: 2018-07-05
,
Jul 13
Issue 863331 has been merged into this issue.
,
Jul 13
,
Aug 2
Friendly ping to get an update as it is marked as RB stable. Thanks..!
,
Aug 2
> Filed internal bug with relevant team, issue 110946935. eae@ any info about the internal bug?
,
Aug 2
No update. I'll ask again. Given that this is a relatively minor issue and the lack of reports or response from the relevant site team I'll go ahead an downgrade this to a P2.
,
Sep 6
This is still happening and M69 has reached stable now. eae@ it would be nice if you can re-ping the internal team again about this topic.
,
Sep 24
This seems to be working for me now, I guess the issue has been fixed in news.google.com.
,
Sep 24
Confirmed. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rbasuvula@chromium.org
, Jun 25 2018Labels: ReleaseBlock-Stable