Setting viewport content maximum scale is not applied immediately
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
People
(Reporter: pietervdvn, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0
Firefox for Android
Steps to reproduce:
When setting the viewport meta contents from a 'maximum-scale=5' to 'maximum-scale=1' while the user did previously zoom in, then the zoom is not set to the new maximum value (in this case 1)
For example:
In the HTML:
<meta content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=5.0, user-scalable=yes" name="viewport" >
IN typescript/javascript:
function resetZoom(){
const metaElems = document.getElementsByTagName("head")[0].getElementsByTagName("meta")
const viewportElement = Array.from(metaElems).find(
(meta) => meta.getAttribute("name") === "viewport"
)
viewportElement.setAttribute("content", "width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=yes")
}
(Notice the maximum-scale=1.0 in the code)
When loading the page (in mobile or on desktop), scaling the page by pinching out (also on Desktop ! ) and then calling resetZoom() when pinched in, this will not reset the zoom immediately.
Tested on Fennec, Librewolf and Firefox nightly on january 10th of 2024
Actual results:
In reality, the page is re-aligned (thus: the upper-left corner of the page is placed at the upper-left corner of the screen), but the zoom is kept.
However, note that when pinching again, firefox wil realize that it has zoomed in beyond the maximum-zoom and will then reset to scale=1.0
Expected results:
The zoom should reset immediately when the above code is called.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•1 year ago
|
||
Curious, what's the use-case for this?
But yeah, this seems to be a bug. Botond, Hiro, do you know if this is known?
|
Reporter | |
Comment 4•1 year ago
|
||
The use case for this can be found on https://dev.mapcomplete.org
This is a map application. As such, pinching out the main screen will zoom in the map.
However, when selecting a pin, the popup appears and will open full screen. Pinching out there will zoom in the text field - so far so good.
However, when closing the popup, we want to reset the user scaling to 1.0. Otherwise, some of the controls might be out of view and might not be reachable, as panning will pan the map, not the view.
In this case, you can compare this behaviour with how chromium handles it, where it does correctly reset the view.
|
|
||
Comment 5•1 year ago
|
||
So that seems like a sensible use case. This seems extremely hacky however. I wonder if having an explicit API to reset the scale (window.visualViewport.scale = 1 or so?) might be a better way of providing such functionality...
|
|
||
Updated•1 year ago
|
|
|
Reporter | |
Comment 6•1 year ago
|
||
It is extremely hacky, but apparently the only way to do this. I got the above solution from some Stackoverflow post.
I'd love the above, proposed solution TBH!
|
||
Comment 7•1 year ago
|
||
As far as I know, there was no such bug report.
And I agree with Emilio. The usecase sounds quite reasonable, but using meta viewport tag to reset the zoom level is awkward. It makes me think the visualViewport.scale should be writable.
|
|
||
Comment 8•1 year ago
|
||
Hah, I was finishing up writing https://github.com/w3c/csswg-drafts/issues/9787 fwiw :)
If you could comment there with the stack overflow post link or what not (I'd also be curious of what the behavior of iOS safari is), that'd help moving it along.
By the way, isn't the same use case valid on desktop? I guess since you don't have the automatic "zoom to focused input" behavior, users are less likely to get into this situation unknowingly?
|
|
Reporter | |
Comment 9•1 year ago
|
||
If you could comment there with the stack overflow post link or what not (I'd also be curious of what the behavior of iOS safari is), that'd help moving it along.
Done, link is over there
By the way, isn't the same use case valid on desktop? I guess since you don't have the automatic "zoom to focused input" behavior, users are less likely to get into this situation unknowingly?
It's complicated. Firefox on desktop allows two ways of zooming, at least on my ubuntu machine. Ctrl+Scroll will zoom in and change the layout (e.g. shifting buttons to the next row if they become to wide). Pinching on my touchpad will 'enlarge' the entire webpage without changing the DOM (as if zooming into a picture). So yes, if they are using the latter way to zoom, they will get into this situation as well.
Chromium-desktop does not support pinch-zooming, only control+scroll.
Gnome Web (a webkit-based browser, just like Safari) supports zooming changing layout with Ctrl+Plus and pinch-zoom as well, similar to FF.
It behaves similarly as FF, not resetting the zoom level.
I don't have access to an Apple device, so cannot test that.
|
||
Comment 10•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Botond, Hiro, do you know if this is known?
I think this is the first time this has come up.
I do think it makes sense for us to match Chrome behaviour here. (At the same time, we should make sure that the accessibility setting "Zoom on all websites" continues to override such zoom level restrictions.)
On the broader topic of the use case here, I wrote some thoughts on the spec issue.
Description
•