Rendering problems when using a specific set of nested elements with certain CSS, with scrollToTop on page load.
Reported by
ros...@garena.com,
Mar 30 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Example URL: https://jsfiddle.net/6ug4289x/6/show/ Steps to reproduce the problem: 1. Visit the example page at https://jsfiddle.net/6ug4289x/6/show/ 2. If text is visible inside the yellow-ish box, move the mouse within the window. 3. If text is still visible, reload the page/frame and repeat step 2. If JSFiddle is not available, an offline version is available as an attachment. What is the expected behavior? Text remains visible on load. What went wrong? Text does not render, even if the yellow-ish container is scrolled. Text will re-render if it is selected, or a full-page redraw is triggered (by adjusting CSS in the Inspector, for example). Does it occur on multiple sites: No Is it a problem with a plugin? No Did this work before? Yes Chromium/Chrome 56 (tested on 56.0.2924.87) Does this work in other browsers? No Chrome 57+ (tested on 57.0.2987.133) Chrome version: 57.0.2987.133 Channel: stable OS Version: Ubuntu 16.04 LTS Flash Version: The bug will not trigger if any of the following are removed: * "position: fixed" CSS on the #tall-menu container. * "background-color" CSS on the #tall-menu container. * "overflow-y" CSS on the #tall-menu container, as scrolling is required to trigger the bug. * "display: inline-block" CSS on the .fake-icon element. * "backface-visibility: hidden" CSS on the .fake-icon element. * Any of the webkit-specific scrollbar CSS definitions. Altering the background-color to a colour instead of "inherit" will not resolve the issue.
,
Mar 30 2017
,
Mar 30 2017
,
Mar 30 2017
Removing Release Block Stable. This is an issue with coordination of scroll position between CC and Blink. The bisect found a reversion, but if you go back to before the original patch, commit 75a7e4cb1ec29ded2e52539259233356caa883c8 (https://codereview.chromium.org/2511473003), I think you'll see the problem again. If you go back before we composite opaque scrollers, the problem will disappear again (although maybe stay on Mac Retina). I'll leave it to flackr@ whether or not this is a dupe of https://bugs.chromium.org/p/chromium/issues/detail?id=677686 It might be an unrelated issue where we do not re-synchronize the scroll position after a scrollToTop setting.
,
Apr 21 2017
Chrome 58.0.3029 still experiences this issue. Btw, I also discovered that the position of the DOM element with the backface-visiblity CSS did not matter to trigger this rendering bug.
,
May 24 2017
Ping; flackr@ can you take a look at this bug? There has been two months since the last real update (from schenney@).
,
Jul 5 2017
For those interested, we have resolved to using the workaround described here: https://jsfiddle.net/upgsys3v/ Basically on scroll event, we toggle nonsense CSS to force a repaint on the scrolling element.
,
Sep 27 2017
I'm unable to reproduce this bug on Chrome 61.0.3163.100 (Official Build) (64-bit) which does not yet include a relanding of the original patch which resolved this issue. Please reopen if you can still reproduce.
,
Sep 28 2017
I am able to reproduce the issue using the example URL, but it is no longer consistent. It will occur in about every one out of 10 page reloads. Chrome version: 61.0.3163.100 (Official Build) (64-bit) OS Version: Ubuntu 16.04.3 LTS
,
Sep 29 2017
How would I go about re-opening this bug ticket? My corporate GSuite e-mail address has changed due to re-structuring. Or should I create a new ticket, as the symptoms of the bug has changed in the current stable build?
,
Sep 29 2017
Reopening as requested by the latest comment. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by durga.behera@chromium.org
, Mar 30 2017Components: Blink>Compositing
Labels: -Type-Compat ReleaseBlock-Stable M-57 OS-Mac OS-Windows Type-Bug-Regression
Owner: flackr@chromium.org
Status: Assigned (was: Unconfirmed)