Intent-to-Ship: Visual Viewport API *and* Inert Visual Viewport

[David Bokan]

Inert Visual Viewport has a previously approved ItS here. This flag shipped but was reverted a milestone later due to removing abilities developers were using without a replacement API.

The Visual Viewport API is that replacement API. I previously posted an ItS here but suspended it to improve the spec and get more consensus. I believe it is now ready for a second look. I'd like to launch the API and the inert flag at the same time so that developers can use the presence of the API to feature-detect the inert flag. The value of this may be diminished somewhat if other vendors ship the API without "inert" or vice-versa but least the situation would be better on Chrome. I'm happy to stagger the launch if API owners feel that'd be better.

It's been a while and a few things have changed so here's an updated Intent for Viewport API:

Contact email

bo...@chromium.org

 

Spec

Spec.

TAG review and re-review.

 

Summary

Explicitly expose properties of the visual viewport (i.e. the viewport affected by pinch-zoom) through a `window.view` object.

Link to “Intent to Implement” blink-dev discussion

Intent-to-Implement

 

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

Example from GitHub repo README. More examples in repo.

 

Interoperability and Compatibility Risk

This is a new feature and Chrome would be the first to ship so there is a small interop risk if other vendors fail to implement it. That said, the API has been endorsed by devs from Safari, Edge, and Firefox. Current versions of these browsers allow a polyfill to work but that could change if they implement the "inert visual viewport".

The API itself should have low compat risk as it's only adding a new feature. The inert flag does have non-trivial compat risk as it changes how various scroll APIs (window.scrollX, window.innerWidth, etc.) work. I believe this is mitigated since flipping it locks a page to the "fully zoomed out" state as far as the page can tell (for more detail, see John Mellor's message on the old intent to ship). Additionally, the inert flag shipped in M48, though we got some significant developer push-back, we didn't receive any reports from users of "broken pages". Another point is that Safari has agreed to this model as well. The current non-inert model has many broken edge-cases so the net effect will likely be positive for users.

For Viewport API:

Edge: Public support

Firefox: Public support

Safari: Public support

Web developers: Positive

 

Is this feature fully tested by web-platform-tests?

Yes: Link

 

OWP launch tracking bug

https://crbug.com/635031

 

Entry on the feature dashboard

https://www.chromestatus.com/feature/5737866978131968

[Rick Byers]

LGTM1

I agree this is ready to go, thanks for all the diligence in getting this right!

There will be some compat impact of the "inert visual viewport" change, but the changes since that I2S was approved are all positive:

• Simon (cc'd) confirmed that he believes the "inert" model is the right behavior for Safari and any deviations are bugs (which he's been fixing in WebKit)
• The rare complaints we got when we had this behavior in Chrome stable for a release can now be addressed by the VisualViewport API
  

Let's make sure the Chrome release blog post links to your excellent explainer / samples to help developers understand what's changing.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/642045c2-534f-4118-accd-84396a509f5c%40chromium.org.

[Chris Harrelson]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8i41CRPNGL3YpYjSytfGR0fbQmc0Z2pi3vmCXxXDR4gA%40mail.gmail.com.

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_sJ32DjcsquamcivRsXS%2Bn_nYAMyOFptogtewg5NCutg%40mail.gmail.com.

[bo...@google.com]

One thing that's come up is that the API puts the VisualViewport on `window.view`. This has some potential compat impact if existing pages are using this name.

This came up because it causes one of our tests to fail with the API on since it looks like this:

var view;

shouldThrow("view = functionThatWillThrow()")

var value = view ? view.someMethod() : 0;

I expect this shouldn't be an issue in most cases as `window.view` can be shadowed so pages that set a global `view` name should continue to work. The only place this falls down is if they check the global `view` for existence prior to having set it and assume something about it like above. I did some quick queries in HTTPArchive and about 50/16,000,000 bodies have the term `window.view` while about 500/16,000,000 have `var view;` (this one's an upper bound as it could be in non-global scope, in both cases I did a regex to discount terms like `window.viewport`). Of the handful of these pages I tried, none produced any JS errors or visible glitches.

I feel like these estimated numbers are small and breakage unlikely enough that it should be safe to continue but I wanted to call it out in case anyone disagrees or has experience with past naming issues like this breaking things.

Thanks,

David

LGTM3.

-mike

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8i41CRPNGL3YpYjSytfGR0fbQmc0Z2pi3vmCXxXDR4gA%40mail.gmail.com.

[bo...@google.com]

Correction, the breaking test isn't a Chromium test, it's part of the public WebGL conformance test suite which means I'd have to update the name in that repo...

[Steve Kobes]

On Fri, Jun 23, 2017 at 11:25 AM, bokan via blink-dev <blin...@chromium.org> wrote:

I expect this shouldn't be an issue in most cases as `window.view` can be shadowed so pages that set a global `view` name should continue to work. The only place this falls down is if they check the global `view` for existence prior to having set it and assume something about it like above.

In addition to the compat scenario you described, I think 'window.view' is hard to use for library authors, because the risk of it being shadowed by the embedding page is so high.  Is there any way to access the API in that case?  Why was the name changed from window.visualViewport?

[Domenic Denicola]

From: sko...@google.com [mailto:sko...@google.com] On Behalf Of Steve Kobes

> In addition to the compat scenario you described, I think 'window.view' is hard to use for library authors, because the risk of it being shadowed by the embedding page is so high.  Is there any way to access the API in that case?  Why was the name changed from window.visualViewport?

Hmm, I'm not sure this is accurate. It's only shadowed if you declare a global variable, which is generally regarded as bad practice and not done in modern JS development. Otherwise, it's always accessible as window.view.

[David Bokan]

There were some complaints that `window.visualViewport` was a bit cumbersome and too "java-like".

Re: modern JS development, I think there's still quite a bit of risk. e.g. https://www.bahn.com has a global `view` variable (in this case it doesn't break with the API change but others might).

I'm going to try changing it back to `window.visualViewport`. I think it's less risky and this is a niche feature anyway so convenience isn't too big of a concern. Worst case, authors can always alias it to something they prefer.

Thanks!

[bo...@google.com]

FYI, filed GitHub issue (Rename `window.view` to `window.visualViewport`)

[Steve Kobes]

On Fri, Jun 23, 2017 at 12:16 PM, Domenic Denicola <d...@domenic.me> wrote:

It's only shadowed if you declare a global variable, which is generally regarded as bad practice and not done in modern JS development.

I agree that it's bad practice, but I disagree that it's not done.  More to the point, in modern JS you often have code from many different components trying to coexist.  If we take the purist attitude of "that's a bad practice so we don't care about it" we are punishing the person trying to use the API for the crimes of some other person who used a global 'view'.

[Chris Harrelson]

Hi, Thanks for bringing this issue to the community's attention. I agree that think that the compat risk of window.view is too high.

To be extra explicit: please block launch of this feature on consensus on the name. From updates on the bug, it sounds like this will be quick.

Chris

[David Bokan]

Update: dbaron@mozilla confirmed that the TAG review didn't bring up `window.visualViewport` as an issue and he personally has no objections. The original person who filed the issue against `window.visualViewport` also agreed that it's fine, details are in https://github.com/WICG/ViewportAPI/issues/42.

I've updated the GitHub repo and spec. The patch to rename the attribute in Blink and WPT is in the CQ. I'll be proceeding with landing the patch to enable the viewport API (using `window.visualViewport`) and inert flag shortly.

Thanks,

David

[Chris Harrelson]

Great! LGTM then.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7469a472-4821-4d27-ae4c-18054a6aed6f%40chromium.org.

[David Bokan]

Just a minor PSA: The draft spec called for having `onresize` and `onscroll` attribute event handlers but the implementation shipped without these by accident. I'm now adding them to the implementation: https://www.chromestatus.com/feature/5644570264076288, https://chromium-review.googlesource.com/c/chromium/src/+/658318