Position Sticky Breaks Links with Scrollable Container
Reported by
p...@invioinc.com,
Apr 17 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3398.0 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Open the attached html file 2. Scroll down until the green div becomes fixed at the top of the window 3. Move the mouse over the "Hover me" link What is the expected behavior? Hovering over the "Hover me" link should show the pointer cursor, and clicking it should navigate to the "about:blank" page. What went wrong? The hover me link stops displaying the pointer cursor and clicking it does nothing. Instead there is a hoverable/clickable region about 40px below where the link is now being displayed. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 68.0.3398.0 Channel: canary OS Version: OS X 10.13.3 Flash Version: This is also broken in previous versions (65, stable), although the behavior exhibited is somewhat different. In that version the link is still hoverable/clickable when the sticky div reaches it's fixed position, but as you continue to scroll the hoverable/clickable region continues to scroll off the screen (it's totally gone around the same time the text "Tall Div" is hidden from view. According to related bug 827224 this used to work, but I cannot be totally sure. This works in Firefox, although the sticky position behavior is a little different. With top: 0; a sticky div in a padded container will stay exactly where it is, instead of scrolling up until it reaches the top of its container as it does in Chrome. In order to get Chrome-like behavior in Firefox I have to set position: -40px; (the amount of padding * -1). I'm not sure which of these is correct, but in either case the link should remain clickable.
,
Apr 18 2018
,
Apr 18 2018
Seems main thread hit testing is wrong.
,
Apr 18 2018
,
Apr 18 2018
,
Apr 19 2018
Able to reproduce issue on reported version 65.0.3325.181, on latest stable 66.0.3359.117 and on latest canary 68.0.3398.0 using Mac Retina 10.13.3, Ubuntu 17.10 HIDPI and Windows HIDPI. i.e; Clicking on Hover me link does nothing. NOTE: Issue is not seen in Non-Retina Mac,Normal Linux and Windows. Issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged. Thanks!
,
Apr 19 2018
,
Apr 27 2018
Attached is a modified version of the original reproduction case which demonstrates a few things I've observed while troubleshooting this: 1. The issue is consistently reproducible without padding of any kind. The attached html page has all padding removed. 2. Beyond links specifically, this issue affects any pointer interactions within the bounds of the element using position: sticky. I've omitted the link from the attached case and placed a hover style on the sticky positioned element itself to demonstrate its lack of interactivity when fixed at the top its container. 3. The pointer interactions which should be targeted within the element using position: sticky end up being targeted at whatever is sitting below the sticky element. To demonstrate this, try scrolling the 'Tall div' text in the attached html page so that it sits directly below the 'Hover me' text, then double click on the 'Hover me' text. If you scroll the 'Tall div' text back into view you'll see that it has been selected by the double click which should have been targeted at the 'Hover me' text.
,
May 3 2018
Can the name of this bug be updated? It happens even if the container doesn't have padding. Has anyone found a work around?
,
May 4 2018
,
Aug 2
Hello everybody, as of 68.0.3440.84 the issue still shows at >100% display scalling on Windows 10 (1803, 17134.191). There is also a problem with the postition sticky content being displayed with inconsistent offset when display scalling varries, anybody experiencing this ?
,
Sep 19
I can't reproduce the problem with the 'test-nopadding-nolink.html' file on Chrome 68.0.3440.106 but it does still appear broken when the scrollable container has padding (see attached file). |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by erikc...@chromium.org
, Apr 17 2018