1409490 - meta-viewport makes elements with inner :active content unclickable.

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Thomas Wisniewski]

Attachment: testcase.html

Tapping on the red square in the attached testcase works in the responsive design mode of desktop Firefox, or when the meta-viewport tag is removed (it also works in Chrome). However, on an Android device (where meta-viewport is honored) the square becomes untappable, and its link cannot be followed.

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi :kats, are you the right person to ask to check this meta-viewport related issue? Your name showed up when I glanced over "meta-viewport" code on searchfox so I am asking. :)

I failed to reproduce this issue on my htc phone. However, this still sounds a concern to me as the original issue was reported on google.com

Comment 2

[Kartikaya Gupta (email:[e-mail])]

I'm familiar with the meta-viewport code although I have no idea why it might cause something like this. I can repro the problem (with the reduced test case) on my Z3C running Nightly. If I load the testcase with "Request Desktop Mode" I can't repro the problem, so I agree it does seem to be related to the viewport. Bizarre. I'll see if I can find the time to do a quick investigation today. Leaving needinfo on me for now.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I turned on some APZ and the main thread hit-testing dumping code. This is some of the output that I got when tapping on the red square:

I/Gecko   (26924): APZCCH: Dispatching single-tap component events to (168,135)
I/Gecko   (26924): Event handling --- (5040,4050):
I/Gecko   (26924): BackgroundColor p=0x92011010 f=0x94761ea8(HTMLScroll(html)(-1)) bounds(0,0,21600,30660) layerBounds(0,0,21600,30660) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip() asr() clipChain() uniform ref=0x94761628 agr=0x94761628 (rgba 0,0,0,0)
I/Gecko   (26924): CanvasBackgroundColor p=0x92011070 f=0x94761c70(Canvas(html)(-1)) bounds(0,0,21600,30660) layerBounds(0,0,21600,30660) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip() asr() clipChain() uniform ref=0x94761628 agr=0x94761628 (rgba 0,0,0,0) layer=0x947b9400
I/Gecko   (26924): BackgroundColor p=0x920110b0 f=0x947f4338(Block(html)(-1)) bounds(0,0,21600,8640) layerBounds(0,0,21600,8640) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip() asr() clipChain() uniform ref=0x94761628 agr=0x94761628 (rgba 0,0,0,0)
I/Gecko   (26924): BackgroundColor p=0x92011110 f=0x947f4938(Block(body)(2)) bounds(480,480,20640,7680) layerBounds(480,480,20640,7680) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip() asr() clipChain() uniform ref=0x94761628 agr=0x94761628 (rgba 0,0,0,0)
I/Gecko   (26924): BackgroundColor p=0x92011170 f=0x91ff4038(Block(a)(1)) bounds(480,480,20640,7680) layerBounds(480,480,20640,7680) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip() asr() clipChain() uniform ref=0x94761628 agr=0x94761628 (rgba 0,0,0,0)
I/Gecko   (26924): BackgroundColor p=0x920111d0 f=0x947f5bf0(Block(div)(0)) bounds(480,480,7680,7680) layerBounds(480,480,7680,7680) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip() asr() clipChain() uniform ref=0x94761628 agr=0x94761628 (opaque 480,480,7680,7680) (rgba 1,0,0,1) layer=0x947b9400
I/Gecko   (26924): WrapList p=0x920112b0 f=0x94761628(Viewport(-1)) z=2147483647 bounds(5040,4050,1,1) layerBounds(5040,4050,1,1) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip() asr() clipChain() ref=0x94761628 agr=0x94761628
I/Gecko   (26924):   BackgroundColor p=0x92011230 f=0x947f4b78(Block(div)(-1) class:moz-custom-content-container) bounds(0,0,21600,30660) layerBounds(0,0,21600,30660) visible(5040,4050,1,1) componentAlpha(0,0,0,0) clip(5040,4050,1,1) asr() clipChain(<5040,4050,1,1> [root asr]) uniform ref=0x94761628 agr=0x94761628 (rgba 0,0,0,0)
I/Gecko   (26924): Got frame 0x947f5bf0 for point (x=5040, y=4050)

As far as I can tell from this output, the hit point (at app units coordinates 5040,4050) falls within the bounds for the 0x920111d0 display item and so it returns that, which corresponds to the <div> element. Since the div is inside the anchor, the event dispatching code should find trigger on the anchor element. If there's a bug it seems to be after the hit-testing step, so likely in the event target chain building code.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Highly unlikely that this had anything to do with event target chain building code, since that happens after we've done hit testing, and just traverses through the parent chain.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

But, this could be because the frame changes or so when we apply the :active state, and then mouse up happens on a different frame, and EventStateManager might think it is different target.

I think we need to tweak http://searchfox.org/mozilla-central/source/dom/events/EventStateManager.cpp#4676,4681-4683 or do what some other browsers do with click handling, and propagate click detection to the common ancestor in general.
This would be fixed in that bug about <button> handling and such, I think. Or some related bug.

Comment 7

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 8

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 9

[Mike Taylor [:miketaylr]]

Tom, does this still reproduce?

Comment 10

[Thomas Wisniewski [:twisniewski]]

Not on my phone in the last Fennec nightly or in Fenix, so this has since been fixed.