Closed Bug 1293491 Opened 9 years ago Closed 4 years ago

window.pageXYOffset always 0 in zoom

Categories

(Firefox for Android Graveyard :: Toolbar, defect, P2)

Product:
Firefox for Android Graveyard
Component:
Toolbar
Version:
48 Branch
Platform:
Unspecified
Android
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: juwagn, Unassigned)

References

Details

Attachments

(1 file, 3 obsolete files)

Testcase
1.06 KB, text/html
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160726073904 Steps to reproduce: Installed latest FireFox 48 mobile android and opened page and zoomed Actual results: The element that should be positioned by JavaScript and counts on window.pageXOffset pageYOffset is wrongly positioned. After checking why, noticed window.pageXYOffset is always zero even after zoom. Than another issue, all elements with positon:fixed do things right after zoom, mean correct displaying, but clickable elements, or better to say, elements that listen to events, they do not react at all in zoomed mode anymore. Expected results: It should work like in previous versions.
OS: Unspecified → Android
Ok, it seems, the bug happens when body gets css property overflow:hidden;
<!DOCTYPE html> <html> <head> <script> var el; window.onresize = window.onscroll = function () { el.style.width = ((window.innerWidth / 100) * 80).toFixed(2) + 'px'; el.style.height = ((window.innerHeight / 100) * 80).toFixed(2) + 'px'; el.style.left = (window.pageXOffset + ((window.innerWidth / 100) * 10)).toFixed(2) + "px"; el.style.top = (window.pageYOffset + ((window.innerHeight / 100) * 10)).toFixed(2) + "px"; el.innerHTML = "window.innerWidth: " + window.innerWidth + "<br>window.innerHeight: " + window.innerHeight + "<br>window.pageXOffset: " + window.pageXOffset + "<br>window.pageYOffset: " + window.pageYOffset; } window.onload = function () { document.body.innerHTML = "<div id=\"dome\" style=\"padding: 0px;height: 80%;width: 80%;font-size: 8px;position: absolute;background-color: #9198C1;\"></div>"; el = document.getElementById('dome'); window.onresize(); } </script> </head> <body width="100%" height="100%" marginheight="0" marginwidth="0" spacing="0" style="width:100%;height:100%;overflow:hidden;"></body> </body> </html>
Once overflow is removed, it begins to work.. That is surely a bug! Because of that I have to add hack only for FireFox mobile.
By the way, the bug with position:fixed elements in zoomed mode has gone too after removing overflow:hidden Despite of fact, how easy it is to fix, I think, that is still a bug, since you should still respect window.pageXYOffset values as good respect position:fixed elements with event firing. I assume, because of that bug with window.pageXYOffset internally the event model seems to expect event areas on wrong positions.
Attached file Testcase —
By the way, with overflow:hidden in body it stops to fire onzoom and onscroll too so if i set intervals, I see at least the innerWidth/Height changing, but pageXYOffset stays zero. ****************** el = document.getElementById('dome'); window.setInterval(function() { window.onresize(); }, 1000); window.onresize(); ***************** ok, it is not a blocker, but since many pages set overflow:hidden in body, especially to avoid scrollbars on desktop browsers, that can get painful by using such pages on mobile devices.
CC'ing David who is working on the Visual Viewport spec [1] and the implementation in Chromium. David, if the body has overflow:hidden, I assume that zooming and then panning will move the visual viewport while the layout viewport remains fixed to (0,0), correct? So the test case in comment 5 would start to fail in Chrome as well, in builds that have the new visual viewport implementation. Can you confirm? [1] https://github.com/WICG/ViewportAPI
Flags: needinfo?(bokan)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Right, only the visual viewport will pan around. This is how it works in Chrome today. This test case works as expected today even though we only pan the visual viewport because we return the visual viewport values in pageX|YOffset and innerWidth|Height. The testcase in comment 5 doesn't work when the chrome://flags/#inert-visual-viewport flag is turned on which is distinct from the visual viewport API. The `inert` flag makes all the existing APIs on window like pageX|YOffset and innerWidth|Height report the dimensions and position of the layout viewport. If `inert` is on, you can replace the `window` properties with the visual viewport API to achieve the same result but `inert` is more controversial so they're separate proposals. (The visual viewport API is turned on using chrome://flags/#enable-experimental-web-platform-features)
Flags: needinfo?(bokan)
I do not understand, why do we discuss about Chrome in FireFox bug forum? Or does FireFox now use Chrome engine?
(In reply to juwagn from comment #9) > I do not understand, why do we discuss about Chrome in FireFox bug forum? This bug concerns behaviour that's not currently standardized, but there is a proposal being considered for standardization [1]. The proposal is already implemented by Chrome. We were just asking Chrome developers for clarification about details of the proposal. > Or does FireFox now use Chrome engine? It does not. Implementers of different browser engines do talk to each other from time to time, to try to achieve interoperability :) [1] https://github.com/WICG/ViewportAPI
Ok, but do not forget one detail, my example does not contain fixed div element, but I think you could add it. Even if it correctly displays the div element with position:fixed, its action area seems to be misaligned when zoomed by body>overlow:hidden making the event firing by touching on such position:fixed divs impossible. I think at least this misaligning has nothing common with Chrome but is purely yours :-)
(In reply to juwagn from comment #11) > Ok, but do not forget one detail, my example does not contain fixed div > element, but I think you could add it. > Even if it correctly displays the div element with position:fixed, its > action area seems to be misaligned when zoomed by body>overlow:hidden making > the event firing by touching on such position:fixed divs impossible. I think > at least this misaligning has nothing common with Chrome but is purely yours > :-) That could be an separate bug. Could you please provide a testcase that demonstrates it?
Flags: needinfo?(juwagn)
To reproduce, just zoom in and scroll into middle of page, the onclick event of button in top middle area stops to fire. As soon the overflow:hidden in body gets changed to overflow:visible, everything continues to fire as expected even after zoom-in.
Attachment #8783076 - Attachment mime type: text/plain → text/html
Attachment #8783085 - Attachment mime type: text/plain → text/html
Attachment #8783085 - Attachment is obsolete: true
Attachment #8783088 - Attachment mime type: text/plain → text/html
(In reply to juwagn from comment #14) > To reproduce, just zoom in and scroll into middle of page, the onclick event > of button in top middle area stops to fire. > As soon the overflow:hidden in body gets changed to overflow:visible, > everything continues to fire as expected even after zoom-in. I can confirm this problem. Going to move it to a separate bug.
See Also: → 1296776
(In reply to Botond Ballo [:botond] from comment #18) > I can confirm this problem. Going to move it to a separate bug. Moved to bug 1296776.
Attachment #8783076 - Attachment is obsolete: true
Attachment #8783088 - Attachment is obsolete: true
I guess we should either make window.pageXYOffset reflect the visual scroll position, or add the visual viewport API so that web developers have a way to access this information. Or both.
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: