Chromium shipping "Inert Visual Viewport" in M48

[Rick Byers]

Hey Matt,

I just wanted to let you know that, as we previously discussed, we decided that it was ultimately better for web compat for completely hide the position/size of the visual viewport from the application and unify on all APIs reporting the layout viewport.

We're shipping this in Chrome 48 (see below), so you can see the behavior active now in Chrome Beta.  Barring any major issues, we expect this feature to reach stable around the end of Jan.  So far we've seen only improvements in web compat from this.

Do you still have plans to try to spec something around viewports?  If there are scenarios where apps really want to know about the position/size of the visual viewport, I'm not opposed to defining new APIs for that, but it does seem like that should be opt-in.  Hopefully we can converge on the exact behavior around viewports.  Last we talked you told me that you guys didn't have a strong reason for leaving some APIs using visual viewport co-ordinates.  I'll be in SYD for the first day of the CSS WG meeting, perhaps we can chat more there?

Thanks,

  Rick

---------- Forwarded message ----------
From: Rick Byers <rby...@chromium.org>
Date: Wed, Oct 14, 2015 at 7:23 PM
Subject: Re: [blink-dev] Intent to Ship: Inert Visual Viewport
To: Yash <yma...@chromium.org>
Cc: blink-dev <blin...@chromium.org>

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 

On Wed, Oct 14, 2015 at 3:44 PM, Yash <yma...@chromium.org> wrote:

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

[Matt Rakow]

Are you shipping the same behaviors on both desktop and mobile?  Historically the visual viewport size and position have always been available on mobile browsers as innerWidth/Height, pageX/YOffset.  Are you seeing any compat issues from rescinding that?  That was our primary motivator, along with the strong desire to have unified behavior between desktop and mobile.  Then again, that was 5 years ago so maybe the web has evolved since then J

 

Definitely hear you about bugs on desktop sites that never anticipated a pinch zoom before though.  If the change to mobile behavior doesn’t wreck sites then changing to completely hidden sounds intriguing.  I think we should have the opt-in viewport APIs available too though as a migration path for anyone who was depending on the previous behavior (I know some of the MSFT apps/sites using WinJS are currently depending on it).

 

Thanks,

-Matt

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

2.      Pinch-zoom in

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

o 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.

[Yash]

Yes, the behavior will be the same on both desktop and mobile. No real issues have been brought to attention yet. From previous discussions, below is a list of things that may break with this change

On Mon, Oct 19, 2015 at 10:02 AM John Mellor <joh...@chromium.org> wrote:

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.

Thanks,

Yash 

[Rick Byers]

Yeah there's definitely risk here.  Maybe we'll be proved wrong and we'll have to disable this, but it's looking good so far.  For me the bottom line for all the below scenarios is that we consider pinch-zoom to be a UI accessibility / legacy compat feature, not a platform feature, so it's reasonable to hide it from the platform by default (as, for example, an OS level screen magnifier would be).

I like the idea of having the opt-in APIs available for cases we haven't anticipated where this is really necessary.  Doing that properly (eg. via standard APIs in CSS OM View spec) seems hard as long as viewports themselves are still unspeced and inconsistent between browsers :-).  Not a reason not to try anyway though.  Eg. we could probably collaborate Edge/blink in the WICG on a lightweight spec for the APIs that make sense for our shared viewport model.

I guess we'll see how our launch goes.  If we hit some serious compat issues, we'll disable and explore the opt-in APIs...

Rick