Closed
Bug 1296776
Opened 8 years ago
Closed 5 years ago
After zooming in on an overflow:hidden page, position:fixed elements no longer receive input events
Categories
(Firefox for Android Graveyard :: Toolbar, defect, P5)
Tracking
(firefox48 wontfix, firefox49 wontfix, firefox50 wontfix, firefox51 fix-optional, firefox52 fix-optional, firefox53 fix-optional, firefox54 fix-optional)
RESOLVED
DUPLICATE
of bug 656036
Firefox 63
Tracking | Status | |
---|---|---|
firefox48 | --- | wontfix |
firefox49 | --- | wontfix |
firefox50 | --- | wontfix |
firefox51 | --- | fix-optional |
firefox52 | --- | fix-optional |
firefox53 | --- | fix-optional |
firefox54 | --- | fix-optional |
People
(Reporter: botond, Assigned: botond)
References
(Blocks 1 open bug)
Details
(Keywords: correctness, regression, Whiteboard: [gfx-noted])
Attachments
(1 file)
3.93 KB,
text/html
|
Details |
STR: 1. Load the attached testcase in Fennec Nightly 2. Zoom in 3. Pan away from the top-left corner of the page (if zooming didn't do so already). 4. Tap the grey element that's fixed to the top of the viewport. Expected results: A dialog appears (triggered by the element's onclick handler). Actual results: No dialog appears It works in the following cases: - The page is modified to make the <body> overflow:visible instead of overflow:hidden. - You keep the visual scroll offset at (0, 0) after zooming in.
Assignee | ||
Updated•8 years ago
|
Summary: After zooming in on an overflow:hidden page, buttons on overflow:hidden elements are no longer clickable → After zooming in on an overflow:hidden page, buttons on position:fixed elements are no longer clickable
Assignee | ||
Updated•8 years ago
|
Summary: After zooming in on an overflow:hidden page, buttons on position:fixed elements are no longer clickable → After zooming in on an overflow:hidden page, position:fixed elements no longer receive input events
Assignee | ||
Comment 1•8 years ago
|
||
I expect the problem here is that Gecko expects position:fixed elements to be positioned relative to the layout scroll offset, while in the compositor we position them relative to the visual scroll offset. To fix this, we may need to make an adjustment to the event coordinates of events that hit fixed-position content as part of the callback transform.
Assignee | ||
Comment 2•8 years ago
|
||
As this is caused by APZ, all versions of Fennec from 48 onwards are going to be affected.
status-firefox48:
--- → affected
status-firefox49:
--- → affected
status-firefox50:
--- → affected
status-firefox51:
--- → affected
Assignee | ||
Updated•8 years ago
|
Keywords: correctness
Whiteboard: [gfx-noted]
Updated•8 years ago
|
Updated•8 years ago
|
Version: unspecified → 48 Branch
Updated•8 years ago
|
Attachment #8783098 -
Attachment mime type: text/plain → text/html
Comment 3•8 years ago
|
||
I'm not sure what to do about this. We could try to fix it using the callback transform as Botond said in comment 1. Another option (which is probably the better long-term fix) is to properly implement the visual viewport semantics that other browsers have (i.e. fix bug 656036).
Updated•8 years ago
|
Comment 4•8 years ago
|
||
I'd like to keep 51 as affected so that this doesn't drop off the radar completely. It's definitely something we should try to fix.
Updated•8 years ago
|
status-firefox52:
--- → affected
Botond, if you have a chance to look at this over the next few releases...
Assignee | ||
Comment 6•8 years ago
|
||
Have we decided on the approach here? (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3) > Another option (which is > probably the better long-term fix) is to properly implement the visual > viewport semantics that other browsers have (i.e. fix bug 656036). The latest comment in bug 656036 says "This is probably a good topic for discussion with the Blink folks that we might be meeting with in a couple of weeks in Toronto." Kats, do you recall if we had such a discussion, and if so, what its outcome was?
Flags: needinfo?(bugmail)
Comment 7•8 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #6) > Kats, do you recall if we had such a discussion, and if so, what its outcome > was? I don't think we had the discussion - the time was taken up discussing things like the Viewport API and scroll-linked animations, IIRC. I think at this point we're the only one that behaves this way and we should probably modify our behaviour to match the other browsers.
Flags: needinfo?(bugmail)
Updated•7 years ago
|
Assignee | ||
Comment 8•7 years ago
|
||
Bug 1123938 tracks the main layout change (supporting visual vs. layout viewports) required to fix this.
Depends on: viewport-compat
Assignee | ||
Updated•6 years ago
|
Comment 9•6 years ago
|
||
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Priority: P3 → P5
Assignee | ||
Comment 10•5 years ago
|
||
This was fixed by bug 656036. No further changes required.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → Firefox 63
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•