1px gap before element with sticky positioning
Reported by
rubenill...@gmail.com,
Feb 17 2017
|
||||||||||||||||||||||||||||||||||||||||||||||||
Issue descriptionChrome Version : 56.0.2924.87 OS Version : OS X 10.12.2 (also seen on Windows 10) URLs : https://jsfiddle.net/rulych/3vrk8pLo/ Other browsers tested: Firefox 51.0.1 : FAIL (mixed results, does not always happen) Safari on iOS 10.2.1 : OK What steps will reproduce the problem? 1. Create a block with a height with decimal px (for example: 29.98px). 2. Create another block right after it and give it "position: sticky" and "top: 0". 3. Scroll down to make the second bar stick to the top. What is the expected result? The sticky bar is rendered at the top of the viewport without a gap. What happens instead of that? The sticky bar is shown with a "transparent" gap of 1px between itself and the top of the viewport. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
,
Feb 20 2017
,
Feb 21 2017
Tested on Mac os 10.12.2 using chrome M56 #56.0.2924.87 and issue is not observed as given in scroll-down image in comment #0. Attached screencast for reference. @rubenillodobrea-- Could you please check attached screencast and confirm us if we had followed correct steps in reproducing the issue , and also please help us by providing the expected result screenshot or screencast ,that would help us in traging the issue better. Thanks!
,
Feb 21 2017
The expected behaviour would be the one you are getting, without a 1px red line on top of the blue box. I have attached a screenshot of this running on Firefox. I have also attached a screencast of the page running on my Chrome. It's hard to distinguish the 1px gap in the video directly, but as you can see, it's consistently showing even after I zoom in. The 1px gap keeps appearing with different window sizes, zoom levels and font base size settings.
,
Feb 22 2017
I'm able to reproduce the issue using the URL provided. Chrome 56.0.2924.67 (Official Build) beta (64-bit) Mac OS X 10.11.6 Screenshots attached.
,
Feb 22 2017
For good measure, here's the same thing after updating to 57.0.2987.54 (Official Build) beta (64-bit).
,
Feb 27 2017
I have tested it on an old MacBook Pro 2012 (!3.3", 1280 x 800) with macOS 10.12.3. The problem is not there. So: MacBook Pro 2012 (13.3", 1280 x 800) : OK macOS 10.12.3 Chrome 56.0.2924.87 MacBook Pro 2016 (13.3", 2560 x 1600) : FAIL macOS 10.12.3 Chrome 56.0.2924.87
,
Mar 1 2017
Thank you for providing feedback. removing "Needs-Feedback" label.
,
Mar 2 2017
Tested the issue on MacBook Air 10.12.2,Windows-7 and linux Ubuntu-14.04 using Chrome stable version 56.0.2924.87 and canary 58.0.3027.3 with the steps mentioned in comment#0 and issue is not reproduced. Reporter@ could you please try in a clean profile without any extensions and let us know your observations if the issue still persists. Thanks..
,
Mar 3 2017
I have tested several MacBooks around the office, and I think that the bug can only be found on high resolution screens (Retina Display). I have attached 5 new tests on 5 different machines here. You can see that the only one that behaves correctly is test number 1, run on a non-Retina Display MacBook Air.
,
Mar 3 2017
Thank you for providing more feedback. Adding requester "sureshkumari@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 3 2017
One more test case. I have used again my own computer, that usually FAILS, but this time I opened the site on a second screen plugged to my MacBook. The second screen is 1920x1080, and test is OK; there is no bug. Only on the primary screen (2560x1600) can the bug be found.
,
Mar 5 2017
Looks like another position: sticky sub-pixel/hi-dpi problem.
,
Mar 7 2017
,
May 23 2017
Yi can you take a look?
,
Feb 12 2018
,
Feb 17 2018
any new updates?
,
Feb 22 2018
This bug was only reproducible on high dpi devices. Now it fails low dpi ones on canary as well. Working version: 64.0.3282.167 Broken version: 66.0.3353.0
,
Feb 22 2018
Found the cause of the regression. Need further investigation.
,
Feb 27 2018
,
Aug 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/20c11c9492d799080819ff38696f09b2102211f6 commit 20c11c9492d799080819ff38696f09b2102211f6 Author: Yi Gu <yigu@chromium.org> Date: Tue Aug 21 19:42:13 2018 Fix the 1px gap between composited sticky and its container Upon calculating the relative position between a composited sticky element and its scroll container, we use EnclosingIntRect instead of RoundedIntRect which causes a scroll offset mismatch between main and cc if the relative position is non integer, e.g. float prepadding. Bug: 693412 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ideab875d2d087b8fe97264d0bddbd7e2393f8e7f Reviewed-on: https://chromium-review.googlesource.com/1183622 Reviewed-by: Philip Rogers <pdr@chromium.org> Reviewed-by: Stephen McGruer <smcgruer@chromium.org> Commit-Queue: Yi Gu <yigu@chromium.org> Cr-Commit-Position: refs/heads/master@{#584884} [add] https://crrev.com/20c11c9492d799080819ff38696f09b2102211f6/third_party/WebKit/LayoutTests/compositing/overflow/composited-sticky-element-with-non-integer-relative-position-to-container-expected.html [add] https://crrev.com/20c11c9492d799080819ff38696f09b2102211f6/third_party/WebKit/LayoutTests/compositing/overflow/composited-sticky-element-with-non-integer-relative-position-to-container.html [modify] https://crrev.com/20c11c9492d799080819ff38696f09b2102211f6/third_party/blink/renderer/core/paint/compositing/composited_layer_mapping.cc
,
Aug 21
,
Aug 21
Issue 876220 has been merged into this issue.
,
Aug 22
,
Aug 30
|
||||||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||||||||||||
Comment 1 by shrike@chromium.org
, Feb 18 2017