Intent to ship: visual viewport on desktop platforms

[Timothy Nikkel]

The visual viewport api provides a way for js to access information about the position and size of the visual viewport, which can diverge from the layout viewport as a result of smooth pinch zooming.

For background on the visual/layout viewport distinction: https://github.com/bokand/bokand.github.io/blob/master/web_viewports_explainer.md

We've been shipping the visual viewport api on Android since mid-2019 https://bugzilla.mozilla.org/show_bug.cgi?id=1512813

We didn't have the ability to do smooth pinch zooming on desktop platforms until late last year, so there wasn't much use for the visual viewport api on desktop until then. The visual viewport api starting to get use in desktop situations now (https://bugzilla.mozilla.org/show_bug.cgi?id=1711989) so it seems like a good time to turn on for desktop.

I intend to land patches next week at the start of the 91 cycle to enable this on desktop.

Edge, Chrome, and Safari are already shipping this on desktop platforms.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551302

Spec: https://wicg.github.io/visual-viewport/

Preference: dom.visualviewport.enabled

web-platform-tests: existing tests in testing/web-platform/tests/visual-viewport

Secure contexts:
This is not restricted to secure contexts.

[Anne van Kesteren]

On Thu, May 27, 2021 at 2:08 PM Timothy Nikkel <tni...@gmail.com> wrote:
> Spec: https://wicg.github.io/visual-viewport/

Do you know what the holdup is on moving this out of WICG? In
principle we don't want to ship things that are not worked on in a
more formal standards group, such as the W3C CSS WG, which I guess is
where this would go. Thanks!

[Jonathan Kew]

On 27/05/2021 13:08, Timothy Nikkel wrote:
> Spec: https://wicg.github.io/visual-viewport/
> <https://wicg.github.io/visual-viewport/>

I don't see anything in the spec about security/privacy implications; do
you know if there has been much thought given to that? It seems like
this API potentially lets the site "watch" the user's behavior in ways
that could be quite unexpected.

Normally, pinch-zoom feels like an entirely local operation on the
device, where I'm effectively taking a magnifying glass to look around
at the page that I already have, not interacting with the site behind it
in any way. (Unlike page-zoom, where the content completely reflows,
perhaps adapting radically to the new size.) This API subverts that
expectation, allowing the site (AIUI) to watch my every move (and
potentially even change things) as I pinch to examine different parts of
a page or image that (I thought) was purely static content once loaded.

Curious if there has been discussion of the potential issues here?

Thanks,

JK

[Botond Ballo]

That's a good question -- I'm not sure, but I filed an issue [1] to
get some clarity on this.

For our part, the impetus for shipping this sooner rather than later
is that its absence is starting to cause webcompat issues on popular
sites (such as the mentioned
https://bugzilla.mozilla.org/show_bug.cgi?id=1711989 causing
pixelation in canvas-based Google Docs when pinch-zooming in, because
the page relies on this API's resize event to re-rasterize text).

Cheers,
Botond

[1] https://github.com/WICG/visual-viewport/issues/74

[Botond Ballo]

There has been one issue [1] related to privacy filed about this spec
so far. It mainly concerns the fact that visual viewport resize events
expose the height of the on-screen keyboard, though based on the
discussion around that, it looks like browsers currently resize the
layout viewport when showing an on-screen keyboard as well, so that
height is already exposed.

As far as tracking the movement of the visual viewport, in my mind
it's not materially different from tracking the movement of the layout
viewport (e.g. via window.scrollX/scrollY), and indeed prior to
Firefox 63 we would reflect the visual viewport offset in
window.scrollX/scrollY itself (though, granted, at the time
pinch-zooming was only possible on mobile). If you have concerns in
this area, it might make sense to reflect them in the linked spec
issue, or file a new spec issue about them.

One final note: being able to react to visual viewport movements and
size changes is an explicit design goal of this API. I am sensitive to
the fact that there is a tradeoff between user control and developer
control here, and that obnoxious uses of this API (e.g. always keeping
an ad inside the visual viewport) have the potential to degrade user
experience. I think there are also worthwhile uses of this API which
are not currently possible (for example, in some applications the user
may want a particular control to remain inside the visual viewport).
Perhaps this is an area where browser interventions (e.g. a mode where
visual viewport updates are not delivered to the website; compare
Firefox on Android's "Always enable zoom" checkbox, which overrides
user-scalable:no in the meta viewport tag) could come in useful,
depending on how the API ends up being used in the wild.

Cheers,
Botond

[1] https://github.com/WICG/visual-viewport/issues/63

[Timothy Nikkel]

Since there didn't seem to be any concerns blocking enabling this I landed the enablement patch and it has now merged to mozilla-central. We can still disable before nightly merges to beta if we deem that action warranted.