Closed Bug 1473108 Opened 6 years ago Closed 6 years ago

Link child's ::before and :active::after content can prevent part of the link from reacting to taps (but clicks work).

Categories

(Core :: DOM: Events, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla64
Tracking Status
firefox63 --- wontfix
firefox64 --- verified

People

(Reporter: twisniewski, Assigned: edgar)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [webcompat:p1])

User Story

Interop bug that affects Tier 1 google web search.

Attachments

(4 files)

Attached file test.html (deleted) —
The provided test-case has a single link (green) which is partly covered by up by the ::before content of a span inside of it (red overlay). This content is normally tappable and clickable. However, when that span also has an :active::after rule applied to it, suddenly tapping no longer registers on the parts of the link which are obscured by the span's ::before or ::after content. Clicks still react as expected. I have not tested with a desktop touchscreen, only on a phone running Fennec. As such this may be Fennec-specific. Chrome on the same phone reacts to taps on the red region as well.
Also note that this affects Google Tier1 interop.
Flags: webcompat?
Blocks: 975444
kats, do you have any ideas here? I don't know if this is likely to be APZ, layout, DOM, or something else. Thanks. I'll go ahead and mark this P1 based on comment 1.
Flags: needinfo?(bugmail)
Priority: -- → P1
So when I reproduce this problem it seems like every other tap on the red part works. That's pretty weird. Without further investigation it could be a bug any of APZ, layout, or DOM. I'll do a little digging, leaving needinfo on me for now.
I turned on/modified some logging in APZEventState.cpp and PositionedEventTargeting.cpp to see what was happening with the event. As far as I can tell the APZ code is working fine - it turns the touch tap into a click, and dispatches the mousemove, mousedown, mouseup events correctly. The target frame for all of these events in PositionedEventTargeting is the Block(_moz_generated_content_before) frame, which is correct. So as far as I can tell the APZ and layout parts of this are fine. So DOM:Events seems like the right place for this to be.
Flags: needinfo?(bugmail)
Thanks for taking a look. Olli, do you know who might be able to investigate this tap event problem on Google at the DOM level?
Flags: needinfo?(bugs)
User Story: (updated)
Whiteboard: [webcompat] → [webcompat:p1]
I'm 99% sure this is because the :active selector causes the ::after content to reframe the event target. So, even though this should probably be fixed in DOM: Events, we could make layout reframe in a more fine-grained way to avoid causing the issue in the first place. This has the same root cause as bug 1448813.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #6) > I'm 99% sure this is because the :active selector causes the ::after content > to reframe the event target. > > So, even though this should probably be fixed in DOM: Events, we could make > layout reframe in a more fine-grained way to avoid causing the issue in the > first place. This has the same root cause as bug 1448813. I guess this is why EventStateManager does not generate MouseClick event for the :active::after content [1]. [1] https://searchfox.org/mozilla-central/rev/c296d5b2391c8b37374b118180b64cca66c0aa16/dom/events/EventStateManager.cpp#5049-5051
Assignee: nobody → echen
Flags: webcompat? → webcompat+
(In reply to Edgar Chen [:edgar] from comment #7) > EventStateManager does not generate MouseClick event for > the :active::after content [1]. > > [1] https://searchfox.org/mozilla-central/rev/c296d5b2391c8b37374b118180b64cca66c0aa16/dom/events/EventStateManager.cpp#5049-5051 EventStateManager could not get the event content [2] because of the UnbindFromTree in nsBlockFrame::DoRemoveFrame [3]. [2] https://searchfox.org/mozilla-central/rev/de7676288a78b70d2b9927c79493adbf294faad5/dom/events/EventStateManager.cpp#5017 [3] https://searchfox.org/mozilla-central/rev/de7676288a78b70d2b9927c79493adbf294faad5/layout/generic/nsBlockFrame.h#538
I just pointed Edgar to bug 1489139 / bug 1461299 which are pretty related. ESM should be able to do similar cleanup to point the target to the non-anonymous element if needed.
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b38223cb4fd1 Part 1: Devirtualize nsIPresShell::GetCurrentEventFrame/GetEventTargetContent; r=smaug https://hg.mozilla.org/integration/autoland/rev/ecce651fad51 Part 2: Make PresShell not point to unbound NAC in event content stack; r=smaug
Depends on: 1497524
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Device: - Samsung Galaxy Note 8 (Android 8.0) Verified in the latest nightly using the test case provided in Comment 0 as well as tapping on the google account icon as described in the github issue. Everything works as expected.
Unfortunately I just tested the tier-1 Google site icon on today's Fennec nightly (with a spoofed Chrome UA), and it still isn't working properly. The test-case is, however. So it appears that there is likely still some other interop issue at play. I'll investigate and file a new bug as appropriate.
Flags: needinfo?(bugs)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: