Pinch to zoom or double tapping breaks links inside position: fixed
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
People
(Reporter: TheOne, Assigned: botond)
References
(Blocks 2 open bugs)
Details
Attachments
(4 files)
Using pinch-to-zoom or double-tap-to-zoom breaks links on some websites. The links are not clickable anymore once you zoom beyond a certain level.
STR:
- Visit https://www.tagesspiegel.de/ . A cookie consent overlay should pop up.
- Zoom in using one of the aforementioned methods.
Expected result:
The links in the overlay should stay clickable no matter what the zoom level is.
Actual result:
Beyond a certain zoom level, the links in the overlay are not clickable anymore.
|
||
Comment 1•3 years ago
|
||
The links are in an iframe that is inside position: fixed, that probably has something to do with it.
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 2•3 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #1)
The links are in an iframe that is inside position: fixed, that probably has something to do with it.
The page structure is notable in that, not only is the iframe inside a div that's position: fixed, but the <html> element of the parent document is position: fixed as well. With this sort of page structure, I can reproduce the hit testing issue in a simple constructed test case as well.
|
|
Assignee | |
Comment 3•3 years ago
|
||
Attached is a reduced testcase. Pinch-zooming in and then clicking on the button inside the iframe demonstrates the problem.
|
|
Assignee | |
Comment 4•3 years ago
|
||
Attached is a frame tree for the root content document in the reduced testcase.
The issue is related to the fact that the FixedList contains a frame (Block(html)(-1)@7fec3282cae0) which has the same content element (the <html> element) as the scroll frame (HTMLScroll(html)(-1)@7fec3282c1a8).
This leads to double application of the <html> element's callback transform (which represents the visual viewport offset) in GetCumulativeApzCallbackTransform(), as follows:
- Iteration starts at the <html> element's primary frame, which is the
Block(html)(-1)@7fec3282cae0. Since this frame has the <html> as its content, the callback transform gets applied once. - However,
seenRcdRsfis not set, because we check for the scroll frame, not its content element. - Iteration then reaches the
ViewportFramewithout encountering the scroll frame (because we're in the fixed list). - We then apply the callback transform again here because we incorrectly think it hasn't already been applied.
|
|
Assignee | |
Comment 5•3 years ago
|
||
|
|
Assignee | |
Comment 6•3 years ago
|
||
The callback transform is stored as a content property, so the relevant
condition is whether we've seen a frame whose content element contains
the RCD-RSF callback transform.
Depends on D116061
Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/09e2d5795110 Fix include-what-you-use error in PositionedEventTargeting.cpp. r=tnikkel https://hg.mozilla.org/integration/autoland/rev/2cf09d6dcf02 Set 'seenRcdRsf' correctly in GetCumulativeApzCallbackTransform(). r=tnikkel
|
||
Comment 8•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/09e2d5795110
https://hg.mozilla.org/mozilla-central/rev/2cf09d6dcf02
|
||
Updated•3 years ago
|
|
||
Comment 9•3 years ago
|
||
I have reproduced this on an affected Nightly build 89.0a1 (2021-04-09).
Confirming this issue as verified fixed on Win 10x64 and macOS 10.15, using Firefox 90.0b4 (2021-06-06).
Thanks!
|
||
Updated•3 years ago
|
Description
•