Touch action bug relating to Overlay div element with 'position: fixed' and SNS share buttons
Reported by
potassiu...@gmail.com,
Feb 3 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Example URL: http://sinst.html.xdomain.jp/zengaku/jkkn/chrome_bug.html Steps to reproduce the problem: 1. Use a touch device (such as Android smart phone and Windows-10 touch screen PC) 2. Place HTML tags of the SNS share buttons 3. Apply CSS style of 'position:relative; z-index:1' to the tag 4. Overlay a div element with 'position:fixed; z-index:2' over the share buttons 5. Tap the buttons through the overlay div. (This bug only occurs at the top and bottom edges of the overlay div.) What is the expected behavior? The tap to the SNS share button should be blocked by the overlay div. What went wrong? Even if the SNS share buttons are totally hidden by the overlay, they behave as if tapped (only when tapped at the top and bottom edges of the overlay div). The CSS 'z-index' may be ignored in touch actions. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 56.0.2924.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 Because this doesn't occur when clicked with mouse, this is not a bug of mouse actions, but a bug of touch actions. Because the button is rendered correctly ('z-index' works well), this is not a bug of rendering.
,
Feb 8 2017
Routing to input team - can anyone confirm this?
,
Feb 9 2017
I've confirmed the bug, repro video attached. Navid, could you take a look (or triage further). Thanks.
,
Feb 9 2017
James, could this be related to OOPIF for those buttons?
,
Feb 9 2017
This is occurring on Android Stable channel so OOPIFs shouldn't be enabled.
,
Jun 13 2018
This looks like it has been fixed. Wish I knew which patch fixed it :/
,
Jul 7
It is true that it was fixed on DevTools. However, it still occurs on my real Android machine. It has not been fixed yet... The version of my "Chrome for Android" is 67.0.3396.87. It is the latest version I can get from Japan now. Note: The latest version of "Chrome for Android" is earlier than the latest version of "Chrome for Desktop" (67.0.3396.99). I don't know why.
,
Jul 7
Uh-oh. This bug has come back even in DevTools on Chrome Canary 69.0.3483.0 . There is no progress.... it has not been fixed yet. Please change the status from "Fixed" to other ones... Repro video:
,
Jul 9
I too can reproduce on Pixel 2XL 69.0.3481.0. This only reproduces for me when I select "opt-out" on chrome://flags/#site-isolation-trial-opt-out. Works as expected when the flag is at default (presumably enabling site-isolation). Navid, since I'm out this week, could you please triage. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by nyerramilli@chromium.org
, Feb 6 2017