Google flight search is broken |
|||||||||||||||
Issue descriptionChrome Version: 61.0.3139.6 OS: Android 7.1.2 NJH47D What steps will reproduce the problem? (1) search for a flight on Google e.g. UA1 (2) (3) What is the expected result? Displays correctly What happens instead? Missing part of display Please use labels and text to provide additional information. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report. Works in dev 61.0.6136.4 but does not work in Canary.
,
Jun 26 2017
,
Jun 26 2017
Able to repro on 61.0.3139.6 on Pixel/ NJH47D but issue is fixed on latest canary 61.0.3141.0.
,
Jul 3 2017
This is still broken on 61.0.3145.0 Also other one boxes like Wimbledon tennis scores.
,
Jul 3 2017
,
Jul 5 2017
Bisect Info: Good Build: 61.0.3141.0 Bad Build: 61.0.3142.0 CL list: https://chromium.googlesource.com/chromium/src/+log/61.0.3141.0..61.0.3142.0?pretty=fuller&n=10000 Culprit: 482304(GOOD), but before 482305(BAD) https://chromium.googlesource.com/chromium/src/+/aee539101b28c16fc9e38fe648ab0f5d017c4aab
,
Jul 5 2017
,
Jul 6 2017
So something weird is going on. I reverted the patch locally which fixes the problem. However, then I just commented out RecordingSource::DetermineIfSolidColor from the if statement until the end... And that causes the problem to re-appear. I will continue my investigation in the morning.
,
Jul 6 2017
Still broken in 61.0.3150.0. after doing search for UA1 you need to scroll up and down a bit for the bug to happen.
,
Jul 6 2017
Not-reduced testcase attached. Repros on Canary / OS X / Retina / 61.0.3144.0 without any devtools emulation things.
,
Jul 6 2017
reduced testcase:
<!DOCTYPE html>
<div style="border-radius:2px;overflow:hidden;">
<div style="overflow:hidden;">
<div style="transform: translate3d(68.5px, 0px, 0px);"></div>
</div>
<div style="position:relative;">
<div style="float:left;">hello</div>
</div>
</div>
,
Jul 6 2017
So, I'm pretty deep down a rabbit hole here, but here's what I have so far (all of this with the solid color patch locally reverted). Given the testcase in #11, - if we detect the layer as solid, then everything works. - if I manually turn this off, every tile is still detected as solid. However, the bug does appear. - I hacked up the code so that we still go down the append solid color quads if the layer _would have been_ detected solid (but we still create tiles and whatnot, just never append those), then things are still broken. - Now, if I make sure that CanHaveTilings returns false in cases where the layer _would have been_ solid, then the bug disappears (!!!) So to put this differently, the quads appended are literally the same since it goes through the same code path. The only difference is potentially damage is done differently (since tiles accumulate damage). But then if there is _no_ damage, it works. If there is extra damage, then it doesn't work. I don't know what else CanHaveTilings would be affecting other than this (from the perspective of layers and trees). My next plan is to see if artificially adding more damage reproduces the bug. +some more people for other ideas
,
Jul 6 2017
To be clear, I'm ok with reverting the patch in question, but I'm convinced that that will simply hide the problem.
,
Jul 6 2017
FWIW when you add damage you expose what's there but maybe wasn't shown if a bug changed something but didn't damage to expose it. We've had some bugs in the past with partial swap where some parts of the page were "changing" out of place, but it was because the whole page was changing, but damage was exposing only some of it, for example. So maybe the layer is white but when we detect solid color we throw away the update rect or something weird like that.
,
Jul 7 2017
I figured it out - reassigning to myself. The bug is in Blink I believe.
,
Jul 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040 commit d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040 Author: Chris Harrelson <chrishtr@chromium.org> Date: Fri Jul 07 22:28:58 2017 Use the ancestor clipping mask layer as the DisplayItemClient for the clip mask. The actual PaintLayer that the mask applies to may have a much smaller visual rect (or even empty), but nevertheless have a child which is not empty. If the visual rect were too small, some paint ops may not be rastered. Bug: 736661 Change-Id: Ib61766057e36f83cfab2be35d08c7773d2b676e1 Reviewed-on: https://chromium-review.googlesource.com/562614 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Stephen Chenney <schenney@chromium.org> Cr-Commit-Position: refs/heads/master@{#485076} [add] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/LayoutTests/paint/overflow/composited-rounded-clip-floating-element-expected.txt [add] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/LayoutTests/paint/overflow/composited-rounded-clip-floating-element.html [add] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/LayoutTests/platform/linux/paint/overflow/composited-rounded-clip-floating-element-expected.png [add] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/LayoutTests/platform/mac/paint/overflow/composited-rounded-clip-floating-element-expected.png [add] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/LayoutTests/platform/mac/paint/overflow/composited-rounded-clip-floating-element-expected.txt [add] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/LayoutTests/platform/win/paint/overflow/composited-rounded-clip-floating-element-expected.png [modify] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/Source/core/paint/FilterPainter.cpp [modify] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/Source/core/paint/LayerClipRecorder.cpp [modify] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/Source/core/paint/LayerClipRecorder.h [modify] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/Source/core/paint/LayerClipRecorderTest.cpp [modify] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp [modify] https://crrev.com/d43ca17f375b2f0cefc8ccaffa22e0c72ea6c040/third_party/WebKit/Source/core/paint/PaintLayerPainter.h
,
Jul 7 2017
|
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by amineer@chromium.org
, Jun 26 2017Labels: -Pri-2 Needs-Bisect ReleaseBlock-Beta M-61 Pri-1