Intent to implement: Visual Viewport API

[Tanushree Podder]

Summary: Mobile web pages contain two viewports, the layout viewport and
the visual viewport. The layout viewport consists of all the page contents
and is specified by the meta-viewport tag. The visual viewport is the
actual visible portion of the page on the screen excluding on-screen
keyboards, areas outside of a pinch-zoom area or any other on-screen
artifact that does not scale with the dimensions of the page. The purpose
of the Visual Viewport API is to allow web developers to explicitly query
the properties of the visual viewport.

Web developers can use this API in situations where they need to position
web page elements to remain visible on the screen regardless of the visible
portion of the web page. For example, if an image needs to be visible
regardless of the pinch-zoom level of the device, it can be positioned
relative to what’s shown on the screen using methods of the Visual Viewport
API.

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

Link to standard: https://wicg.github.io/visual-viewport
<https://wicg.github.io/visual-viewport/#the-visualviewport-interface>

Platform coverage: Available on both Android and Desktop. However, the API
will be useful on desktop after desktop pinch zooming has been implemented.
Without pinch zooming, there is no difference between the visual viewport
and the layout viewport.

Estimated release: In Firefox 63, we will release the API without event
handler attributes behind a pref. The event handlers onresize and onscroll
may be pushed to a later release. The timeline for enabling it by default
has not been decided yet.

Preference behind which this will be implemented:
dom.visualviewport.enabled

Is this feature enabled by default in sandboxed iframes? Yes

If allowed, does it preserve the current invariants in terms of what
sandboxed iframes can do? Yes

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1477829

Do other browser engines implement this?

Shipped: Chrome 61 (
https://bugs.chromium.org/p/chromium/issues/detail?id=635031)
Opera 48 (
https://www.chromestatus.com/feature/5737866978131968)

In development: Safari (
https://webkit.org/status/#feature-visual-viewport-api)

web-platform-tests:
Test suite:
https://searchfox.org/mozilla-central/source/testing/web-platform/meta/visual-viewport

Currently, these tests are expected to fail as the Visual Viewport API has
not been implemented yet.

Bug to enable tests: https://bugzilla.mozilla.org/show_bug.cgi?id=1477610

Secure contexts: Yes

[Boris Zbarsky]

On 7/23/18 7:36 PM, Tanushree Podder wrote:
> Secure contexts: Yes

I'm not sure what this line means here. The spec does not restrict this
API to secure contexts, right? Do we plan to thus restrict it in our
implementation?

I just filed https://github.com/WICG/visual-viewport/issues/56 on some
obvious issues with the spec being underdefined that we would have
presumably run into in the course of implementing it...

Implementing looks good to me, but we should make sure issues like that
are shaken out before we ship.

-Boris

[Michael de Boer]

> On 24 Jul 2018, at 01:36, Tanushree Podder <tpo...@mozilla.com> wrote:
>
> Summary: Mobile web pages contain two viewports, the layout viewport and
> the visual viewport. The layout viewport consists of all the page contents
> and is specified by the meta-viewport tag. The visual viewport is the
> actual visible portion of the page on the screen excluding on-screen
> keyboards, areas outside of a pinch-zoom area or any other on-screen
> artifact that does not scale with the dimensions of the page. The purpose
> of the Visual Viewport API is to allow web developers to explicitly query
> the properties of the visual viewport.
>
> Web developers can use this API in situations where they need to position
> web page elements to remain visible on the screen regardless of the visible
> portion of the web page. For example, if an image needs to be visible
> regardless of the pinch-zoom level of the device, it can be positioned
> relative to what’s shown on the screen using methods of the Visual Viewport
> API.

About the desktop perspective: is pinch-to-zoom a completely separate thing from full-page-zoom as can be controlled right now with Ctrl+ and Ctrl- using the
keyboard?
If that’s the case, I can see synchronization issues between the two features when they’re both in use.
My perception is that pinch-to-zoom is really full-page-zoom, but using the pointer coordinates as focal point instead of [0,0] and step-less zooming behaviour, instead of clamping to predefined steps.
If that’s not the case, I’d say the new API seems usable on desktop already once the page has been zoomed in.

Thanks,

Mike.

[Cameron McCormack]

On Tue, Jul 24, 2018, at 12:22 PM, Boris Zbarsky wrote:
> On 7/23/18 7:36 PM, Tanushree Podder wrote:
> > Secure contexts: Yes
>
> I'm not sure what this line means here.

I updated the intent to implement template at https://wiki.mozilla.org/ExposureGuidelines#Intent_to_implement to make it clearer what this is asking.

[Boris Zbarsky]

On 7/24/18 4:22 AM, Michael de Boer wrote:
> About the desktop perspective: is pinch-to-zoom a completely separate thing from full-page-zoom as can be controlled right now with Ctrl+ and Ctrl- using the
> keyboard?

Yes. As a simple example, full-page-zoom does relayout (e.g. can change
where linebreaks happen). pinch-to-zoom does not do relayout, as far as
I know.

-Boris

[Botond Ballo]

On Tue, Jul 24, 2018 at 4:22 AM, Michael de Boer <mde...@mozilla.com> wrote:
> About the desktop perspective: is pinch-to-zoom a completely separate thing from full-page-zoom as can be controlled right now with Ctrl+ and Ctrl- using the
> keyboard?

Yes. The two have different behaviours (as Boris mentioned, one
reflows the page, one does not).

> If that’s the case, I can see synchronization issues between the two features when they’re both in use.

Could you elaborate? As far as I'm aware, other browsers like Chrome
and Safari support both at the same time on desktop.

> My perception is that pinch-to-zoom is really full-page-zoom, but using the pointer coordinates as focal point instead of [0,0] and step-less zooming behaviour, instead of clamping to predefined steps.

Currently, pinch gestures on a trackpad are hooked up to perform
full-page zooming on desktop. This is a temporary measure until pinch
zooming is implemented on desktop. Once pinch zooming is implemented
on desktop, pinch gestures will be hooked up to perform that.

Thanks,
Botond

[tpo...@mozilla.com]

On Monday, July 23, 2018 at 10:22:48 PM UTC-4, Boris Zbarsky wrote:
> On 7/23/18 7:36 PM, Tanushree Podder wrote:
> > Secure contexts: Yes
>
> I'm not sure what this line means here. The spec does not restrict this
> API to secure contexts, right? Do we plan to thus restrict it in our
> implementation?
>

Chrome supports the Visual Viewport API for non-secure contexts. As the spec does not mention any restrictions to secure contexts, we will also default to Chrome's behavior and make the API available to non-secure contexts for now. However, I have filed an issue (https://github.com/WICG/visual-viewport/issues/57) to discuss if the API should be restricted to secure contexts.