rendering issue after change position from sticky back to relative with forced repaint
Reported by
homyu.sh...@gmail.com,
Jan 26 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36 Steps to reproduce the problem: 1. open test page https://jsfiddle.net/4mLo9fmg/2/ or "reduced test case file" 2. scroll a bit to test out the sticky function, at the beginning it should functioning correctly 3. and then click "screw it" button. 4. Try scroll around again. What is the expected behavior? After #3 the sticky should still working because the position is set back to sticky and top is correctly set. What went wrong? Sticky element doesn't get rendered correctly despite dom model shows it is at correct position, forcing a repaint by using javascript will cause it to render to correct position, but scroll again the rendering issue come back. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 56.0.2924.76 Channel: stable OS Version: OS X 10.10.5 Flash Version: Shockwave Flash 24.0 r0 "Sticky" is still NOT WORKING PERFECTLY on chrome 56, using javascript to set its position back to relative and then visit offsetTop property will cause rendering issue
,
Jan 26 2017
I tested against Version 58.0.2993.0 (Official Build) canary (64-bit) on MAC it is still not fixed
,
Jan 26 2017
Did you try the file you attached, or the JSFiddle test case?
I did not try the former, but the latter works.
However, trying it as a standalone document, it is indeed still broken.
data:text/html,<!doctype html><style>.nav { top: 72px; position: sticky; background: white; padding: 20px; }</style><div style="height:300px"></div><div class="nav"> Nav </div><div style="height:100px"></div><button onclick="p()">do</button><div style="height:2300px"></div><script>var a = document.querySelector('.nav');function p() { a.style.position = 'relative'; a.style.top = '0'; a.offsetTop; a.style.position = 'sticky'; a.style.top = '72px';}</script>
Sorry for dismissing it so easily earlier!
,
Jan 26 2017
Thanks for the repro.
,
Jan 27 2017
Yes, it looks like canary build does working on jsfiddle, but not the "reduced test file"
,
Feb 18 2017
Confirmed that issue still reproduces on latest Chrome using the reduced test case from #3. Minimal reproduction is at http://output.jsbin.com/xomuruk . So far my observations are: 1. Issue only reproduces if the scroller is the root scroller; if I place the content of http://output.jsbin.com/xomuruk in a overflow: scroll DIV the sticky works after the switch. 2. It seems that sticky constraints *are* being re-calculated for the DIV after it is made sticky again (LayoutBoxModelObject::updateStickyPositionConstraints). I need to determine if these constraints are correct, and if they are being used.
,
Feb 18 2017
3. Issue does not reproduce at all if the sticky is composited.
,
Feb 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c4550918a382319dd463b8ca7735f5b32f39ccbe commit c4550918a382319dd463b8ca7735f5b32f39ccbe Author: smcgruer <smcgruer@chromium.org> Date: Thu Feb 23 12:05:37 2017 Mark elements as viewport constrained when they become sticky positioned Previously changing an element from sticky to non-sticky would remove it from the set of viewport constrained elements, but the inverse was not honored. This caused broken behavior if you cycled the position for an element between sticky and any other position. BUG= 685658 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Review-Url: https://codereview.chromium.org/2706673002 Cr-Commit-Position: refs/heads/master@{#452467} [add] https://crrev.com/c4550918a382319dd463b8ca7735f5b32f39ccbe/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-style-change-expected.html [add] https://crrev.com/c4550918a382319dd463b8ca7735f5b32f39ccbe/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-style-change.html [modify] https://crrev.com/c4550918a382319dd463b8ca7735f5b32f39ccbe/third_party/WebKit/Source/core/frame/FrameViewTest.cpp [modify] https://crrev.com/c4550918a382319dd463b8ca7735f5b32f39ccbe/third_party/WebKit/Source/core/layout/compositing/CompositingInputsUpdater.cpp
,
Feb 28 2017
Issue 672441 has been merged into this issue.
,
Feb 28 2017
,
Feb 28 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by phistuck@chromium.org
, Jan 26 2017Labels: OS-Windows
Status: WontFix (was: Unconfirmed)