Issue metadata
Sign in to add a comment
|
CSS column-count render bug since chrome update 70.0.3538.77 (Official Build) (64-bit)
Reported by
jas...@ennik.com,
Nov 8
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Steps to reproduce the problem: The issue is demonstrated here: 1. https://jsfiddle.net/L2z4srwp/1/ 2. After scrolling the first table notice the unrendered rows bottom left 3. After subsequently resizing the browser window the rows get redrawn What is the expected behavior? Rows get redrawn in the first place upon scrolling without resizing window What went wrong? Ever since upgrade to chrome v70.0.3538.77, my domain users have been having issues with the rendering of tables when a CSS { column-count: 2 } is applied. When scrolling a table within a fixed height div, the scrolled area remains unrendered (white). When the browser window is resized, the content gets redrawn and the content appears as it should have been rendered during scrolling. Did this work before? Yes Previous version to .77 Chrome version: 70.0.3538.77 Channel: stable OS Version: 10.0 Flash Version: See link below for screenshots https://stackoverflow.com/questions/53208296/css-column-count-render-bug-since-chrome-update-70-0-3538-77-official-build-6
,
Nov 8
,
Nov 8
,
Nov 8
I think this is a dupe of other missing content bugs.
,
Nov 8
,
Nov 8
,
Nov 13
Friendly ping to look into this issue and to provide further update on this issue as it has been marked as a stable blocker. Thanks!
,
Nov 13
Reminder M71 Stable is approaching VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thank you. Requesting to take a look at M71 blockers ASAP due to upcoming Thanksgiving holidays next week.
,
Nov 14
The root issue seems to be that, at least in the example in #7, overflow content underneath a scroller that is fragmented is not put into the same fragment as the scroller. e.g. the content that is visible without any scroll offset is in a fragment with fragment logical top 0, and the content that is not visible is in a second fragment with logical top 316. This issue was exposed when I stopped re-computing fragments on every non-composited scroll. If you re-compute the fragments on every non-composited scroll, then everything looks ok, because once the elements are scrolled to be visible, they switch fragment. It seems like the right fix is to put all of this content onto the first fragment. Then when it is scrolled without re-computing fragments, content will display correctly.
,
Nov 14
,
Nov 15
The test in #7 seems to fail because of the bottom margin, which doesn't fit in the first column, so we get a break and another (empty) column (margins are truncated at column boundaries). It seems that all it takes for it to fail is having at least one column after the scrollable container. Putting everything inside a scrollable container in the same fragment sounds like a good solution. However, note that we may actually brutally slice a scrollable container into multiple fragments as a last resort in some cases, when the column isn't tall enough to fit the whole thing; see attachment. Not an important case, though. Pretty useless to slice a scrollable container like that.
,
Nov 15
Reminder M71 Stable is approaching VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thank you. Requesting to take a look at M71 blockers ASAP due to upcoming Thanksgiving holidays next week.
,
Nov 16
,
Nov 20
I'm going to land a workaround for the moment, since it appears it's not very simple to implement the proposal from #10 right away.
,
Nov 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1d2bbd2fe44c0a91cb87362f8e3e38a9eddc6a37 commit 1d2bbd2fe44c0a91cb87362f8e3e38a9eddc6a37 Author: Chris Harrelson <chrishtr@chromium.org> Date: Fri Nov 23 23:09:57 2018 [Regression] Force subtree paint property update on scroll of fragmented content. This is necessary because overflow-scrolled content can be placed into a non-visible fragment clip. When scrolling into view, those clips need to be adjusted to allow the content to be visible. Long-term we can remove this slow path. Bug: 903287 Change-Id: Ia237d72f91084aa4ef125a9ba765b5d00143f48b Reviewed-on: https://chromium-review.googlesource.com/c/1344219 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#610684} [modify] https://crrev.com/1d2bbd2fe44c0a91cb87362f8e3e38a9eddc6a37/third_party/WebKit/LayoutTests/TestExpectations [add] https://crrev.com/1d2bbd2fe44c0a91cb87362f8e3e38a9eddc6a37/third_party/WebKit/LayoutTests/fragmentation/scrolling-contents-scroll-expected.html [add] https://crrev.com/1d2bbd2fe44c0a91cb87362f8e3e38a9eddc6a37/third_party/WebKit/LayoutTests/fragmentation/scrolling-contents-scroll.html [modify] https://crrev.com/1d2bbd2fe44c0a91cb87362f8e3e38a9eddc6a37/third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc
,
Nov 24
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by woxxom@gmail.com
, Nov 8