Issue metadata
Sign in to add a comment
|
Text in list elements only renders at some window sizes and flickers during resize
Reported by
p...@zynga.com,
Nov 18 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36 Example URL: http://www.w3schools.com/code/tryit.asp?filename=F0DNCXBLBUQ8 Steps to reproduce the problem: 1. Load the URL (or copy the code and run it locally) 2. Resize the browser and watch the text flicker What is the expected behavior? The elements / text should render consistently at all sizes and not flicker during resize. What went wrong? Text flickers and does not appear for some window sizes. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? Yes Mac Chrome Version 53.0.2785.143 (64-bit) (I think it works on all versions of 53 and before) Does this work in other browsers? No Mac Safari Version 9.1.1 (11601.6.17) Has a similar issue - the text is thinner, but still visible Chrome version: 54.0.2840.87 Channel: n/a OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 23.0 r0 I tried to get the example code as small as possible - I believe the embedded flash and the iframe are both required - not sure if the positioning of them matters (the iframe is on top of the swf). Removing most of the css will also not cause the issue - the simplest change to make the page work as intended is to remove this line: #navFooter ul li {position:relative;}
,
Nov 23 2016
[mac triage] adding tags for further triage. Note I couldn't repro in 56.0.2914.3 dev
,
Nov 23 2016
Looks like a compositing issue.
,
Nov 24 2016
Tested on Mac OS 10.11.6 using chrome stable M54 #54.0.2840.98 and issue is not reproduced. Observed similar behavior in M53 and M54 chrome versions. Text appears in all window sizes. Attached screencast for reference. @pfay-- Could you please provide us the expected result screencast , that would help us in traiging the issue better. Thanks !
,
Nov 28 2016
,
Nov 28 2016
@hdodda You must allow / run the flash plugin to see the issue. I attached a video with the original bug to show the behavior. Providing a new video with me reproing on Mac OSX 10.11.5 on latest stable 54.0.2840.98 and on Canary 57.0.2935.0. On latest 54 I was running flash 23.0.0.207, on Canary I was running flash 24.0.0.170, don't think flash version is impactful.
,
Dec 6 2016
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 12 2016
Reproduced on Linux. At some window sizes, or on some resizes, the text is not painted or is painted black (I think the former). First step is to figure out if this is an invalidation issue vs a painting issue. Bisect requested. Flash definitely needs to be enabled.
,
Dec 12 2016
,
Dec 14 2016
Reduced test case (expected: a blue square; actual: the blue square disappears) attached, and pasted here for ease of discussion:
<!DOCTYPE html>
<div id="container" style="width:760px; margin-left:auto; margin-right:auto; position:relative; overflow:hidden">
<object type="application/x-shockwave-flash" width="400" height="50"></object>
<div id="below-object" style="position: relative">
<ul>
<li style="display: inline; position: relative">
<div id="blue" style="width: 50px; height: 50px; float: left; background-color: blue"></div>
</li>
</ul>
</div>
</div>
The blue div (float:left under a position:relative <li>) is painted on the GraphicsLayer created for "under-object", but visualRect is computed against the LayoutView.
The flash object is just to force compositing and avoid squashing of the "below-object" layer. The test can be reduced further not to depend on flash plugin if we can achieve compositing/no-squashing in other ways.
,
Dec 14 2016
This is another complication of paintInvalidationContainer: floating objects should not use the paintInvalidationContainer of its inline container (<li> whose paintInvalidationContainer is the LayoutView), but of its containing block ("below-object" which is itself a paintInvalidationContainer).
,
Dec 15 2016
Move to M-57 because the bug is not new and the change will be a bit risky.
,
Jan 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/78b26d84270257a830facd6477ef6e3ff59aca66 commit 78b26d84270257a830facd6477ef6e3ff59aca66 Author: wangxianzhu <wangxianzhu@chromium.org> Date: Fri Jan 06 21:03:13 2017 Fix geometry mapping issues for float under inline Floating object belongs to its containing block, no matter if it's under an inline and no matter if the inline is layered, stacked, or paint invalidation container. This requires us to specially handle floating objects for LayoutObject::paintingLayer(), LayoutObject:: container(), paint invalidator, etc. BUG= 666553 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Review-Url: https://codereview.chromium.org/2575423003 Cr-Commit-Position: refs/heads/master@{#442046} [add] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/LayoutTests/paint/invalidation/compositing/float-under-composited-inline-expected.html [add] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/LayoutTests/paint/invalidation/compositing/float-under-composited-inline-expected.txt [add] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/LayoutTests/paint/invalidation/compositing/float-under-composited-inline.html [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/LayoutGeometryMap.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/LayoutObject.h [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/LayoutObjectTest.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/PaintInvalidationState.h [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/VisualRectMappingTest.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/svg/LayoutSVGBlock.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/layout/svg/LayoutSVGBlock.h [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/paint/PaintInvalidator.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilder.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilder.h [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilderTest.cpp [modify] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/web/tests/LayoutGeometryMapTest.cpp [add] https://crrev.com/78b26d84270257a830facd6477ef6e3ff59aca66/third_party/WebKit/Source/web/tests/data/rgm_float_under_inline.html
,
Jan 6 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Nov 18 2016