Intent to Ship: Inert Visual Viewport

[Yash]

Contact emails

yma...@chromium.org, bo...@chromium.org

Spec

There is no spec outlining how the APIs below should work under pinch to zoom.

Summary

This change modifies the following API methods outlined in the CSSOM View Module to be relative to the layout viewport:

core/frame/Window.idl

long innerWidth;

long innerHeight;

double scrollX;

double scrollY;

double pageXOffset;

double pageYOffset;

scroll(double x, double y);

scrollTo(double x, double y);

scrollBy(double x, double y);

core/dom/Element.idl

double scrollTop;

double scrollLeft;

Motivation

Having window.scroll properties being relative to the visual viewport breaks some pages under pinch-zoom.

Consider this example:

1. Go to http://www.nytimes.com/

2. Pinch-zoom in

• Android/Pixel: Two-finger zoom in gesture on the screen

• Macbook: Two-finger zoom in gesture on trackpad

3. Click on the gear button in the top right corner to bring down the fixed-style settings menu.

Expected: The settings menu pops up right beneath the gear button

Actual: The settings menu pops up at an offset from the gear button

The plan is to have all APIs reflect the layout viewport.

Compatibility Risk

No significant compatibility risk. The way the above methods should work under pinch zoom is not specified. Firefox and safari have a different pinch to zoom model. Currently, IE follows the same model as us and this change is a step in convincing them that the above methods should be relative to the layout viewport.

Ongoing technical constraints

None.

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

Yes.

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

[Rick Byers]

I support shipping this.  The fact that there's no spec for this should raise some eyebrows.  Let me elaborate a little for those that care:

This is really a continuation of the "virtual viewport" work we've discussed in the past and already shipped (but didn't have a proper chromestatus entry or intent discussion around - mostly due to the effort originally pre-dating the blink fork and living entirely in the compositor).  Basically how the platform behaves under pinch zoom has never been specified and varies wildly between browsers.  We're trying to fix this, and continue to discuss it in the CSS WG with some promising progress.  But there's some open questions about what's most web compatible, which we feel is best addressed by just trying to ship the changes we think are right.

This particular change is about whether pinch zoom is really completely transparent to JavaScript or not.  We originally felt it should be, but hit some minor issues and decided to first try matching IE's behavior (which is the state currently).  We've now learned this hurts behavior on some sites when doing pinch zoom and causes a bunch of confusion when some of the CSS OM APIs reflect the visual viewport while others reflect the layout viewport (which are different only under pinch-zoom).  Edge engineers told us they didn't have a strong reason for the specific choice they made other than that it seemed most web compatible.  If we can show evidence that our approach of total transparency is better, then I think we've got a shot at convincing them to switch (and getting the other vendors to match).

The bottom line for compatibility here is that it's already nearly impossible to build an app that responds to pinch zoom in some custom way (especially across browsers).  We see pinch zoom as really a browser UI feature for coping with legacy content, not a core part of the web platform (as evidenced by most modern mobile sites disabling pinch zoom).  However we feel it's important to polish and rationalize virtual viewport behavior because we hope to use it in additional scenarios in the future which are more core to the platform (like on-screen keyboard behavior).

Rick 

[Chris Harrelson]

LGTM

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

[John Mellor]

I'm very happy to see people working on this area. To demonstrate how bad it currently is, visit https://jsbin.com/gijizo/quiet on desktop and mobile.

On desktop, the JavaScript-positioned divs (in blue) are layed-out exactly the same as the CSS-positioned divs (in green), and stick perfectly to the edges of the screen, however fast you move the scrollbar.

On mobile, it's buggy even before you zoom:

• JS-positioned divs lag behind scrolling (whilst touch event latency may be unavoidable here given the compositor scrolling architecture, we should be able to prevent that during flings where we can predict future scroll positions).
• When you scroll up/down, only the "bottom js v2" div sticks to the bottom of the screen (modulo lag); the "bottom js v1" and "bottom js v3" divs are usually out by the height of the omnibox. This is because the url bar hiding/showing as you scroll is inconsistently exposed to script.

But it's simply disastrous once the user pinch zooms:

• All four "v2" divs stick to the visual viewport (the physical screen), which is inconsistent with CSS fixed position (the green divs), as noted in the intent to ship.
• The other JS-positioned (blue) divs do even weirder things, that are sometimes similar to CSS fixed position, but rarely exactly the same, even allowing for lag.
• (There's also weird behavior, whereby the page expands vertically and horizontally when you scroll down or to the right; this is just a side-effect of the blue divs getting positioned incorrectly, and hence expanding the page).

Yash wrote:

> No significant compatibility risk. The way the above methods should work under pinch zoom is not specified. Firefox and safari have a different pinch to zoom model.

It's likely that some websites do UA-sniffing or feature-detection to deal with the varying behaviors here.

I think a better argument for this having low compatibility risk is that this doesn't change the behavior when the page is fully zoomed out, and when the user zooms in it continues to seem to script that the page is fully zoomed out (hence pinch zoom is undetectable), so we should remain within a well-tested subset of webpage behaviors.

The kinds of things that might nevertheless break with this change are:

1. Ad/Analytics libraries will incorrectly track what parts of the page are onscreen during pinch zoom.
   
2. Lazy-loading scripts will think more of the page is onscreen than is actually onscreen during pinch zoom, so may download unnecessary resources.
   
3. Zoomed websites will no longer be able to detect when a touch gesture (e.g. drag) reaches the edge of the screen (e.g. in order to scroll automatically).
4. Toolbars using JS-positioning to stick to the visual viewport (screen edges) will no longer do so (but they were buggy already, see above), and will instead require scrolling to get to (in some cases, you'll have to scroll the entire length of the document before the toolbar becomes visible).
   

But these are all relatively minor, and I'd argue the consistency benefits outweigh these risks.

--John

*: (We could improve #4 by only scrolling the layout viewport when the visual viewport reaches the edge of the layout viewport, rather than scrolling it whenever the visual viewport moves -- i.e. "Pin to outer viewport (bump scroll)" of http://johnmellor.net/static/pinch-zoom-position-fixed/ -- this would make it significantly easier to access fixed position toolbars whilst zoomed in. But that's orthogonal to this change.)

[TAMURA, Kent]

LGTM2.  It looks a reasonable behavior change.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

LGTM3. Mixed coordinate systems in these APIs seems very weird, and
the goal of making the visual viewport invisible to web contents, at
least in existing APIs, is a very good one.

[David Bokan]

On Monday, October 19, 2015 at 10:02:48 AM UTC-4, John Mellor wrote:

*: (We could improve #4 by only scrolling the layout viewport when the visual viewport reaches the edge of the layout viewport, rather than scrolling it whenever the visual viewport moves -- i.e. "Pin to outer viewport (bump scroll)" of http://johnmellor.net/static/pinch-zoom-position-fixed/ -- this would make it significantly easier to access fixed position toolbars whilst zoomed in. But that's orthogonal to this change.)

 We've already made this change (I sent out a PSA a few weeks back), it should ship in M47 :).

[David Bokan]

Update: It seems more people were relying on this than we had anticipated. See http://crbug.com/571297. Given that there's no satisfactory workaround for some of the use cases we're planning on putting this back behind a flag in M49 and re-shipping once we add a new API for querying the information removed by this change.