Menu stripped off in espn.com
Reported by
josh.lin...@gmail.com,
Sep 30
|
|||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3566.0 Safari/537.36 Example URL: ESPN.com Steps to reproduce the problem: 1. Go to espn.com 2. Click on any sport along the top line (tabs/list/menu whatever it is) 3. Drop-down doesn't work What is the expected behavior? It SHOULD populate across the screen - so you don't have to click to go to a sport THEN access standings, scores, etc. What went wrong? It is CUTTING OFF the menu Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 68 Does this work in other browsers? Yes Chrome version: 71.0.3566.0 Channel: canary OS Version: OS X 10.14.0 Flash Version: I tried to open the report but someone in INDIA claimed it was working in INDIA. Well here's a clue - I'm not in INDIA. I don't have cricket and ----- tasting - this is the USA site (default) and IT DOES NOT WORK
,
Oct 1
Unable to reproduce the issue on mac 10.13.3 using chrome reported version #71.0.3566.0. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Navigated to espn.com which got redirected to espn.in 2. Clicked on any sport along the top line (tabs/list/menu whatever it is) 3. Observed that Drop-down worked without any issues. As per comment #0, it seems that there is no issue with drop down in espn.in(India region)and issue exist in USA site. Hence, forwarding the issue to MTV team for further triaging. Thanks...!!
,
Oct 1
Here we go again. I've attached Mac-INCOGNITO (Chromium 71.0.3566.0) VERSUS Mac-INCOGNITO (Chrome 69 release 69.0.3497.100) Note it's the same exact issue on Windows (7 and 10). And same exact thing on other computers (Macs) - I switch between two Macs based on daily needs.
,
Oct 3
Can reproduce fairly consistently on Windows 10. The popup menu container is given the correct size yet the layer is cut-off. It uses an animation (transition) to expand and it appears to stop after a frame or two in some cases. Removing the transition avoids the problem.
,
Oct 3
Repros on Linux too with Beta channel (M-70). Bisects on Linux to this (bisected twice to verify): https://chromium.googlesource.com/chromium/src/+log/1ad5c66907292930c378b882c1634fad9b2b29eb..f5e8bf6941f0fb31103ad926e86729d45b276e01 Of which the most likely candidate is: [PE] Stop dirtying compositing inputs on any layout for the root PaintLayer https://chromium.googlesource.com/chromium/src/+/46520ae13478333fe882e79041b667e5a3112796 Sometimes it works before the page has fully loaded, or maybe before some onload handler has run. Given the bisect, maybe that's because something else is dirtying things at that point in the page load cycle.
,
Oct 4
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 4
,
Oct 5
,
Oct 8
Updating summary and labels.
,
Oct 9
Just as a reminder, we are less than 1 week away from M70. Any updates yet on this bug?
,
Oct 9
Update #1: verified that reverting https://chromium.googlesource.com/chromium/src/+/46520ae13478333fe882e79041b667e5a3112796 makes the bug go away. Debugging now to find out where we are under-invalidating.
,
Oct 9
,
Oct 10
I found the root cause. It's that visual overflow is changing, and we are correctly detecting that, but the PaintLayer whose visual overflow is updating is squashed into another one that is not its descendant, and so the call to SetNeedsGraphicsLayerUpdate in CompositingInputsUpdater does not result in a rebuild of the squashing layer. CL in progress: https://chromium-review.googlesource.com/c/chromium/src/+/1274895
,
Oct 11
Let's hope this fixes a couple of other issues that I suspect are related, particularly http://crbug.com/893439
,
Oct 11
Fix is done in and in CQ.
,
Oct 11
,
Oct 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2bd342fdf320e2e38bc48ef3a71355c8815b2b21 commit 2bd342fdf320e2e38bc48ef3a71355c8815b2b21 Author: Chris Harrelson <chrishtr@chromium.org> Date: Thu Oct 11 19:44:37 2018 Set dirty bits for GraphicsLayerUpdater correctly for PaintLayers that are squashed. Previously, a PaintLayer whose compositing inputs changed didn't propagate those changes to the squashing layer, if the PaintLayer was squashed. Bug: 890638 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0ad3bb79aa15e59eca9efd443f40cd5b66dcd583 Reviewed-on: https://chromium-review.googlesource.com/c/1274895 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: vmpstr <vmpstr@chromium.org> Cr-Commit-Position: refs/heads/master@{#598894} [add] https://crrev.com/2bd342fdf320e2e38bc48ef3a71355c8815b2b21/third_party/WebKit/LayoutTests/compositing/squashing/overflow-change-squash-non-ancestor-expected.html [add] https://crrev.com/2bd342fdf320e2e38bc48ef3a71355c8815b2b21/third_party/WebKit/LayoutTests/compositing/squashing/overflow-change-squash-non-ancestor.html [modify] https://crrev.com/2bd342fdf320e2e38bc48ef3a71355c8815b2b21/third_party/blink/renderer/core/paint/compositing/compositing_inputs_updater.cc [modify] https://crrev.com/2bd342fdf320e2e38bc48ef3a71355c8815b2b21/third_party/blink/renderer/core/paint/compositing/compositing_inputs_updater.h
,
Oct 11
Requesting merges. Will test on Canary tomorrow and also update.
,
Oct 11
This bug requires manual review: We don't branch M71 until 2018-10-11. Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 11
This bug requires manual review: We are only 4 days from stable. Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 11
Let's verify this in canary tonight.
,
Oct 12
Verified working fine on Canary Mac 71.0.3578.0 / Retina.
,
Oct 12
Also, I think this merge is very safe. It only adds more cases of setting dirty bits to the system, which can only result in additional recalculations and no crashes.
,
Oct 12
Removing merge request for M71. The fix made it in time for the branchpoint.
,
Oct 12
branch:3538
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c77f77c82ed718b2e9163a4a7c99c0554e2b466 commit 4c77f77c82ed718b2e9163a4a7c99c0554e2b466 Author: Chris Harrelson <chrishtr@chromium.org> Date: Fri Oct 12 23:01:03 2018 Set dirty bits for GraphicsLayerUpdater correctly for PaintLayers that are squashed. Previously, a PaintLayer whose compositing inputs changed didn't propagate those changes to the squashing layer, if the PaintLayer was squashed. Bug: 890638 TBR=chrishtr@chromium.org (cherry picked from commit 2bd342fdf320e2e38bc48ef3a71355c8815b2b21) Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0ad3bb79aa15e59eca9efd443f40cd5b66dcd583 Reviewed-on: https://chromium-review.googlesource.com/c/1274895 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: vmpstr <vmpstr@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#598894} Reviewed-on: https://chromium-review.googlesource.com/c/1279346 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#990} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [add] https://crrev.com/4c77f77c82ed718b2e9163a4a7c99c0554e2b466/third_party/WebKit/LayoutTests/compositing/squashing/overflow-change-squash-non-ancestor-expected.html [add] https://crrev.com/4c77f77c82ed718b2e9163a4a7c99c0554e2b466/third_party/WebKit/LayoutTests/compositing/squashing/overflow-change-squash-non-ancestor.html [modify] https://crrev.com/4c77f77c82ed718b2e9163a4a7c99c0554e2b466/third_party/blink/renderer/core/paint/compositing/compositing_inputs_updater.cc [modify] https://crrev.com/4c77f77c82ed718b2e9163a4a7c99c0554e2b466/third_party/blink/renderer/core/paint/compositing/compositing_inputs_updater.h
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c77f77c82ed718b2e9163a4a7c99c0554e2b466 Commit: 4c77f77c82ed718b2e9163a4a7c99c0554e2b466 Author: chrishtr@chromium.org Commiter: chrishtr@chromium.org Date: 2018-10-12 23:01:03 +0000 UTC Set dirty bits for GraphicsLayerUpdater correctly for PaintLayers that are squashed. Previously, a PaintLayer whose compositing inputs changed didn't propagate those changes to the squashing layer, if the PaintLayer was squashed. Bug: 890638 TBR=chrishtr@chromium.org (cherry picked from commit 2bd342fdf320e2e38bc48ef3a71355c8815b2b21) Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0ad3bb79aa15e59eca9efd443f40cd5b66dcd583 Reviewed-on: https://chromium-review.googlesource.com/c/1274895 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: vmpstr <vmpstr@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#598894} Reviewed-on: https://chromium-review.googlesource.com/c/1279346 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#990} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Oct 12
|
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Oct 1