Issue metadata
Sign in to add a comment
|
Visual Ghosting of removed DOM elements on Retina displays
Reported by
ccon...@gmail.com,
Apr 29 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36 Example URL: https://jsfiddle.net/j64paxar/1/ Steps to reproduce the problem: 1. Navigate to https://jsfiddle.net/j64paxar/1/ with the window on a retina monitor 2. Click the span labeled "Click" 3. Notice that the replaced span is still visible behind the new span What is the expected behavior? The old span should be visually removed and you should only see "Spluh" What went wrong? Attached is a video of the visual bug. The CSS is the bare minimum that we have been able to reproduce it with. Its odd that it only happens on retina monitors. Scrolling down and back up makes it disappear and the bug does not occur if you without refreshing move the page from a retina to a non-retina monitor. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 50.0.2661.94 Channel: stable OS Version: OS X 10.10.5 Flash Version: Shockwave Flash 21.0 r0
,
Apr 29 2016
,
Apr 29 2016
This testcase requires float:left on the element with the .item class. It looks like we find the incorrect paint invalidation container, when the scroller is composited. (Repros on all platforms with --enable-prefer-compositing-to-lcd-text Xianzhu, might be easy for you to diagnose given your recent work on floats. Or maybe it's a regression.
,
Apr 30 2016
This is not a recent regression. Bisected to https://chromium.googlesource.com/chromium/src/+log/58fd4f4c6ec98f7cc04fbfe039ed8bf6ad36a05d..a7aa648b4726884717287ac12b284cfd6054e49f blink: https://chromium.googlesource.com/chromium/blink/+log/f007c95..0171005 which doesn't seem to contain susceptible changes. Will continue to investigate.
,
May 2 2016
Thanks mstensho@opera.com for the test case. The problem occurs when we allocate CompositedLayerMapping for the div whose 'display' is changed to 'relative'. The paint invalidation from PaintLayerCompositor::allocateOrClearCompositedLayerMapping() doesn't work for this case because it will invalidate on wrong old paintInvalidationContainer which is found using the new layer's new stacking information. This is similar to the case that we call invalidatePaintIncludingNonCompositingDescendants() from LayoutBoxModelObject::styleWillChange() when the object's layer may cease to be a stacking context. Now I understand why the paint invalidation during compositing update didn't work.
,
May 2 2016
Sorry, didn't intend to change the owner. Just found we do invalidate paint on correct paint invalidation container when the div becomes a stacked layer. The case is handled in PaintLayer::insertOnlyThisLayerAfterStyleChange() by comparing the new and old paint invalidation containers. Investigating why the paint invalidation doesn't work.
,
May 2 2016
This bug is actually a regression of subsequence caching. It did occur in old revisions before chrishtr@ fixed it in https://codereview.chromium.org/1337233002. https://codereview.chromium.org/1937303003 will fix this bug.
,
May 2 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/89dcd6c67c48e8dfdb520a25556b50121cef75ba commit 89dcd6c67c48e8dfdb520a25556b50121cef75ba Author: wangxianzhu <wangxianzhu@chromium.org> Date: Mon May 02 23:55:41 2016 Set layers needsRepaint along the original compositingContainer chain if stacking status changes BUG= 607768 TEST=paint/invalidation/relative-position-under-composited-scroll.html Review-Url: https://codereview.chromium.org/1937303003 Cr-Commit-Position: refs/heads/master@{#391107} [add] https://crrev.com/89dcd6c67c48e8dfdb520a25556b50121cef75ba/third_party/WebKit/LayoutTests/paint/invalidation/relative-position-under-composited-scroll-expected.html [add] https://crrev.com/89dcd6c67c48e8dfdb520a25556b50121cef75ba/third_party/WebKit/LayoutTests/paint/invalidation/relative-position-under-composited-scroll.html [modify] https://crrev.com/89dcd6c67c48e8dfdb520a25556b50121cef75ba/third_party/WebKit/Source/core/paint/PaintLayer.cpp
,
May 3 2016
,
May 3 2016
Your change meets the bar and is auto-approved for M51 (branch: 2704)
,
May 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a4284ce0da0d11811ae65fcf9b84564f841731a9 commit a4284ce0da0d11811ae65fcf9b84564f841731a9 Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Tue May 03 23:31:14 2016 Set layers needsRepaint along the original compositingContainer chain if stacking status changes BUG= 607768 TEST=paint/invalidation/relative-position-under-composited-scroll.html Review-Url: https://codereview.chromium.org/1937303003 Cr-Commit-Position: refs/heads/master@{#391107} Review URL: https://codereview.chromium.org/1945983002 . Cr-Commit-Position: refs/branch-heads/2704@{#366} Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251} [add] https://crrev.com/a4284ce0da0d11811ae65fcf9b84564f841731a9/third_party/WebKit/LayoutTests/paint/invalidation/relative-position-under-composited-scroll-expected.html [add] https://crrev.com/a4284ce0da0d11811ae65fcf9b84564f841731a9/third_party/WebKit/LayoutTests/paint/invalidation/relative-position-under-composited-scroll.html [modify] https://crrev.com/a4284ce0da0d11811ae65fcf9b84564f841731a9/third_party/WebKit/Source/core/paint/PaintLayer.cpp
,
May 3 2016
,
May 4 2016
Rechecked this on MAC 10.11.4 for chrome version 51.0.2704.36 on Retina Pro Display and fix is working as intended. Clicked on the text and it replaces with the new text completely. Adding TE-Verified labels. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by yutak@chromium.org
, Apr 29 2016