757208 - :target pseudo element is not supported on Firefox Mobile

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Jeremie Patonnier :Jeremie]

The following experiments are menu build with CSS

 - http://ie7nomore.com/fun/responsive-menu/menu3.html
 - http://ie7nomore.com/fun/responsive-menu/menu3b.html
 - http://ie7nomore.com/fun/responsive-menu/menu3c.html
 - http://ie7nomore.com/fun/responsive-menu/menu4.html

They relay on the :target pseudo-element to work.

It works perfectly with Safari on iOS, Opera Mobile and even with Firefox on desktop, but it fail with Firefox Mobile

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that works just fine on Fennec with :target

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase based on one of the menu testcases that works on desktop but not on Fennec

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Er, the right testcase that shows the problem

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  This has nothing to do with :target per se.  On Fennec, tapping that "menu" button is not traversing a link at all, afaict, so the URI never changes and hence :target doesn't match.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimalish testcase

Comment 6

[Boris Zbarsky [:bzbarsky]]

So something really weird is happening here.  The link definitely goes :active, so _Gecko_ is seeing the click.  But the link never gets traversed.  If I replace either of the "absolute"s in the stylesheet with "relative", it works.  If I use a <span> child of <a> instead of :before, it works.

This last makes me suspect the Fennec UI is involved somehow: under the hood Gecko would treat the <span> and :before pretty identically.  Plus the fact that it works on desktop and all.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Matt, any idea what might be going on here?

Comment 8

[Wesley Johnston (:wesj)]

We do some fancy stuff for :active for tap highlights. I'll look at this.

Comment 9

[Wesley Johnston (:wesj)]

This is related to us "moving" the click to be on the nearby element. I'm guessing that the generated content is not included when we call element.getClientRects() and we attempt to move the click to a rect of area 0x0? Digging more....

Comment 10

[Boris Zbarsky [:bzbarsky]]

element.getClientRects() won't include the generated content, correct, since it only includes boxes for the element itself.  I guess the <span> case worked because then you moved the click to the <span>...

Comment 11

[Wesley Johnston (:wesj)]

Attachment: Patch

We bail if the rect has 0 with and 0 height. In this case we don't actually hit that because the element is 0 width but 16px height. We then move the click to the very edge of the zero-width element which doesn't actually click on it. Just next to it I think.

I don't think we should bail entirely if the element is 0 width and height. Fixing that fixes this. Probably some other "smarter" options if you don't like this.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

Waiting for some tests so we are sure we don't regress

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 626138 [details] [diff] [review]
Patch

The patch itself is fine. I just want some tests.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

Wes, what's the deal here?

Comment 15

[Wesley Johnston (:wesj)]

Tests got held up. Landed this for now:

https://hg.mozilla.org/integration/mozilla-inbound/rev/200969fd3313

Comment 16

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/200969fd3313

Comment 17

[Boris Zbarsky [:bzbarsky]]

More likely Firefox 19... but looks like no one actually set up the right target milestones in this product.  :(