Closed Bug 757208 Opened 9 years ago Closed 8 years ago

:target pseudo element is not supported on Firefox Mobile

Categories

(Firefox for Android :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 19
Tracking Status
blocking-fennec1.0 --- soft
fennec 17+ ---

People

(Reporter: Jeremie, Assigned: wesj)

References

()

Details

Attachments

(2 files, 3 obsolete files)

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
tracking-fennec: --- → ?
Component: General → Style System (CSS)
Product: Fennec Native → Core
QA Contact: general → style-system
Attachment #625856 - Attachment is obsolete: true
blocking-fennec1.0: --- → ?
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.
Attached file Minimalish testcase
Attachment #625854 - Attachment is obsolete: true
Attachment #625857 - Attachment is obsolete: true
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.
Component: Style System (CSS) → Layout: View Rendering
QA Contact: style-system → layout.view-rendering
Whiteboard: [parity-opera][parity-webkit]
Matt, any idea what might be going on here?
We do some fancy stuff for :active for tap highlights. I'll look at this.
Assignee: nobody → wjohnston
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....
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>...
Assignee: wjohnston → nobody
Component: Layout: View Rendering → General
Product: Core → Fennec
QA Contact: layout.view-rendering → general
Assignee: nobody → wjohnston
Attached patch PatchSplinter Review
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.
Attachment #626138 - Flags: review?(mark.finkle)
tracking-fennec: ? → 15+
blocking-fennec1.0: ? → soft
Waiting for some tests so we are sure we don't regress
Comment on attachment 626138 [details] [diff] [review]
Patch

The patch itself is fine. I just want some tests.
Attachment #626138 - Flags: review?(mark.finkle) → review+
tracking-fennec: 15+ → 17+
Wes, what's the deal here?
Flags: needinfo?(wjohnston)
Tests got held up. Landed this for now:

https://hg.mozilla.org/integration/mozilla-inbound/rev/200969fd3313
Flags: needinfo?(wjohnston)
https://hg.mozilla.org/mozilla-central/rev/200969fd3313
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 16
More likely Firefox 19... but looks like no one actually set up the right target milestones in this product.  :(
Product: Fennec → Firefox for Android
Target Milestone: Firefox 16 → Firefox 19
You need to log in before you can comment on or make changes to this bug.