[MD History] Item background sometimes does not appear on items with a time gap separator |
|||||||||
Issue descriptionVersion: 58.0.3018.0 (Developer Build) (64-bit) OS: Linux Steps to reproduce: 1. Navigate to chrome://history 2. Scroll down through History till you find results with a time gap See screenshot for the result. The background sometimes does not extend down to cover the time gap separator. Devtools shows that the #background element is still sized and positioned correctly, but part of it is just painted wrong. Resizing the browser window (forcing a repaint?) will cause the error to disappear, until new items are scrolled into view. A bisect gives the following result: https://chromium.googlesource.com/chromium/src/+log/93f3aad56213f965b074f584c764e24bd9db5480..d8442090e4581bca53869f94c34a82e906a92910 Therefore, assigning to wangxianzhu@ to take a look. Since this is a regression affecting a Chrome WebUI, I'd appreciate it if you could help find a workaround or a fix before M58 branches next week. I'll try and follow-up with a reduced repro case soon.
,
Feb 23 2017
Here's a significantly reduced test case: https://jsbin.com/pudehubafe/1/edit?html,output It still needs the Polymer <iron-list> element to reproduce, which makes me think the bug is triggered by reusing DOM elements of different sizes.
,
Feb 24 2017
Please apply appropriate OS labels. Thank you.
,
Feb 26 2017
I've reproduced on Windows and Linux, but I'm pretty sure this affects all desktop OSes.
,
Feb 27 2017
Thanks tsergeant@ for the test case. I was able to reproduce the issue on the latest canary(58.0.3024.0) of Windows and Linux. Somehow couldn't repro the same on 58.0.3024.0 of Mac OS 10.12.3. Just to update, M-58 gets branched in 3 days from now and this is marked as Beta blocker. Would be good to have this fixed before branch point.
,
Feb 27 2017
Will fix this before branch point.
,
Feb 27 2017
,
Feb 27 2017
,
Feb 27 2017
The iron-list manages a pool of items which are dynamically bound to a subset of source items. Whether the bug can be reproduced with the reduced test case depends on the number of items in the pool which depends on the height of the window.
Reproduced with a debug version of content_shell with the window is enlarged in height, and slowly scroll the contents. It asserts under-invalidation of paint property:
[1:1:0227/112210.045893:606967031167:FATAL:FindPropertiesNeedingUpdate.h(146)] Check failed: *m_originalProperties->cssClip() == *objectProperties->cssClip(). Property was updated without the layout object ("LayoutBlockFlow (positioned) DIV class='background'") needing a paint property update.
Original:
parent=0x2aebb438790 localTransformSpace=0x2aebb5bc6a0 rect=-5,0 1004x55.3906 radii:(tl:0x0; tr:0x0; bl:0x0; br:0x0) directCompositingReasons=none
Updated:
parent=0x2aebb438790 localTransformSpace=0x2aebb5bc6a0 rect=-5,0 1004x40.3906 radii:(tl:0x0; tr:0x0; bl:0x0; br:0x0) directCompositingReasons=none
It seems that we miss setNeedsPaintPropertyUpdate when used value of css clip changes. The css clip property doesn't change:
clip: rect(auto 999px auto -5px);
but the used value of css clip changes when size of the object changes.
Minimized test case attached.
,
Feb 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4f2629181c9c12fcca25f436910afbb2b5789bb6 commit 4f2629181c9c12fcca25f436910afbb2b5789bb6 Author: wangxianzhu <wangxianzhu@chromium.org> Date: Tue Feb 28 00:08:43 2017 Fix paint property under-invalidation of CSS clip on resize BUG= 694875 TEST=*PaintPropertyTreeUpdateTest.CSSClipDependingOnSize* CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Review-Url: https://codereview.chromium.org/2716203003 Cr-Commit-Position: refs/heads/master@{#453404} [modify] https://crrev.com/4f2629181c9c12fcca25f436910afbb2b5789bb6/third_party/WebKit/Source/core/layout/LayoutBox.cpp [modify] https://crrev.com/4f2629181c9c12fcca25f436910afbb2b5789bb6/third_party/WebKit/Source/core/paint/PaintPropertyTreeUpdateTests.cpp
,
Feb 28 2017
Verified the fix on the latest canary(58.0.3026.0) of Windows-10, Mac OS 10.12.3 as per the attached test case(clip.html) in C#10 and jsbin in C#3. This is working as intended. Hence adding the verified label. wangxianzhu@: Please close the issue if there is no further work to be done here.
,
Feb 28 2017
,
Feb 28 2017
,
Feb 28 2017
Thanks for the quick fix! |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by wangxianzhu@chromium.org
, Feb 22 2017