Issue metadata
Sign in to add a comment
|
elements in with "position: sticky" can become unclickable when content is scrolled behind them
Reported by
michael....@airbnb.com,
Mar 28 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Example URL: https://jsfiddle.net/6bvqy3gz/3/ Steps to reproduce the problem: 1. Open https://jsfiddle.net/6bvqy3gz/3/ 2. Hover over link text (it should be underlined while hovering) 3. Scroll down 4. If underline is still present move mouse off and back on to link 5. In some cases the elements hover style will no longer be applied (we have seen inconsistent behavior depending on what screen is viewing the page) What is the expected behavior? Link should continue to be clickable when the parent container is scrolled. What went wrong? We have noticed that despite the sticky element being rendered on top, in some cases elements below the sticky element will be targeted by mouse events. (I tested this added opacity the the sticky element, and adding hover styles to the elements that scoll behind the sticky element). 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: 65.0.3325.181 Channel: stable OS Version: OS X 10.13.3 Flash Version:
,
Mar 29 2018
,
Mar 30 2018
,
Apr 3 2018
We can confirm it, we are seeing the same in Chrome on macOS but not in other browsers. Is there a simple tool to check where this regression was introduced if it is a regression? Something like mozregression that anyone can recommend?
,
Apr 3 2018
It's not as simple as mozregression but still doable: 1) download the script from https://www.chromium.org/developers/bisect-builds-py and install python v2 (not v3) 2) run the script: python bisect-builds.py -a mac64 -g 300000 -b 999999 -g specifies the last known good build, 300000 is Chrome 41 -b specifies the first known bad build, 999999 implies Canary 3) observe the bug and input g or b for good/bad status in the script window until the script produces the changelog link 4) copypaste that final block of text here 5) repeat steps 2-3 to ensure you get the correct results
,
Apr 3 2018
michael.hayes@ Thanks for the issue. Able to reproduce this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 67.0.3386.0 and Stable 65.0.3325.181 as per the original comment. Bisect Information: =================== Good Build: 65.0.3312.0 (Revision - 527163) Bad Build : 65.0.3313.0 (Revision - 527467) On executing the per-revision bisect script, below is the Changelog URL: https://chromium.googlesource.com/chromium/src/+log/c8f9ef323c67d6207df5ec0383503653a41ee113..ed23c5622a815ec34ef4160db567cf83bccfcc41 From the above Changelog, suspecting the below change: Reviewed-on: https://chromium-review.googlesource.com/849417 chrishtr@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Adding ReleaseBlock-Stable as this is a recent regression. Please feel free to remove it if it is not applicable. Thanks.
,
Apr 3 2018
Judging by the suspected CL it might be a duplicate of issue 827224 .
,
Apr 3 2018
,
Apr 4 2018
But https://bugs.chromium.org/p/chromium/issues/detail?id=827224 is newer as far as I can see.
,
Apr 4 2018
That report was already assigned to the developer which is why this one is merged. Sometimes even ancient reports get merged into a newer one.
,
Apr 4 2018
Ah ok, thanks for the clarification. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by lgrey@chromium.org
, Mar 28 2018