New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 571297 link

Starred by 117 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 489206



Sign in to add a comment

Pinch-zoom state no longer exposed to JavaScript, eg. via window.innerWidth/height

Reported by anthonyo...@gmail.com, Dec 20 2015

Issue description

Steps to reproduce the problem:
1. run "javascript:alert(window.innerWidth);" and get a value like "800" pixels
2. zoom web page in or out to change size
3. run the same JavaScript and value has not changed like in all previous WebViews

What is the expected behavior?
window.innerWidth should change on zoom as the content area dimensions have changed because of the zoom. That is, a 100px x 100px content area, after being zoomed out, should report bigger dimensions like 1000px x 1000px.

What went wrong?
window.innerWidth seems to report screen width or some other value, not taking into account zoom.

Did this work before? Yes This worked in all previous WebView versions including previous dev channel release of System WebView and way back to Gingerbread and probably previous to that.

Chrome version: 48.0.2564.48  Channel: n/a
OS Version: 5.1.1
Flash Version: none

I think this should be a very high priority. This will likely break many, many sites. Is there a workaround?
 
Showing comments 16 - 115 of 115 Older

Comment 16 by bokan@chromium.org, Jan 11 2016

There is no way to get the dimensions of the visual viewport. As noted above, if your app needs to respond to pinch-zoom gestures, its best to build it as you need using TouchEvents and CSS transforms.
Just want to chime in here:

- Mobile Safari does report the updated dimensions when pinch-zoomed on a website, via innerWidth and innerHeight.

- Prior to v48, Chrome Emulator was behaving the same as above.

- Window "resize" event is no longer firing as of v48 when performing a pinch-zoom.
I know, it is a special case, but I am working for a testing tool vendor who has the requirement to know, where on the device screen a dom element is positioned. It is fine for me, that you decide, that the layout viewport is what a web developer should care about, but I do not see the point why you need to keep the visual viewport a secret. Please consider to expose it in any way, or at least expose some alternative to the client bounding rect that used to be the simplest way to get the screen coordinates of an element, when making changes whith such a huge impact. 

I've spent days following your coordinate system changes and you really make my work live significantly harder ;)
Thanks for the feedback. The goal is not to make anyone's life harder, however, the old situation was using these properties in a way they were not originally designed for. This led to lots of cases where pages would break under pinch-zoom and other scenarios, leading to a poor experience for users.

That said, we're not against exposing some bits of the visual viewport for esoteric use cases like the one you mention (I can see this being useful in testing tools in particular). However, the way we'd do that is adding new APIs. Additionally we'd definitely want to standardize these with the other browser vendors.
So you're basically said Chrome will no longer support (until new APIs are provided) viewport (pinch-zoom) resizing events, viewport dimensions read, or any way for web devs to accommodate pinch-zoom gestures?
Right, for ordinary web development you shouldn't be relying on the browser's pinch-zoom implementation - it's a browser UX feature and not part of the web platform. If you want pinch as part of your experience, CSS/JS gives you the tools to build it. See my comments in #7 and #14 for the details. 
OK great, thank you for the clarification and guidance!
I've got an application that adjusts its UI layout to the viewport.

That way user's pinch-zooming updates the size of primitives (fonts, buttons, icons), but keeps the whole of UI accessible within physical screen.

Essentially it's similar to how you can change desktop font scaling (or in a crude way you simply change resolution of your monitor). When you scale up your fonts OS-wide, relative sizes of toolbars, splitters etc. change to accommodate bigger fonts. But your toolbar at the top and your status bar at the bottom are still visible both at the same time.

Your paper/magnifying glass paradigm makes sense for "page-like" sites. But to the "app-like" it completely breaks the UX.

Note that Chrome is the only browser that is "broken" in that sense. In all others (and I do support a wide variety, man) the zoom works as expected. When it breaks I fix it.

Your demo is very welcome, but it only solves a narrow part of the problem AND it uses a complex library. As you've said it doesn't scroll properly neither it works as expected on desktop browsers.

Again, in every other browser I can do that reflow-to-viewport with 10-20 lines of JS.

And just to drive the point further, the link you've quoted is very supportive of the existing status-quo, which you've deviated from:

http://www.quirksmode.org/mobile/viewports2.html
"Therefore it’s very lucky that the Browser Wars gave us two property pairs. [...] As to the visual viewport, it is measured by window.innerWidth/Height. Obviously the measurements change when the user zooms out or in, since more or fewer CSS pixels fit into the screen."
>> That way user's pinch-zooming updates the size of primitives (fonts, buttons, icons),
>> but keeps the whole of UI accessible within physical screen.

And how can you do this with the current status quo? You'd have to manually resize all your UI. To your point about keeping UI in view, I've updated my example (http://bokan.ca/demo/pinch-zoom-reflow.html) to keep a position: fixed footer bar that doesn't zoom. Note how naturally this works and how it behaves properly. Getting position: fixed elements to behave sanely with browser pinch-zoom in Safari (actually, all browsers treat position: fixed in pinch-zoom differently) would be...challenging. 

>> Your paper/magnifying glass paradigm makes sense for "page-like" sites.
>> But to the "app-like" it completely breaks the UX."

Agreed - which is why you shouldn't use it for "app-like" scenarios. Browser pinch-zoom was designed for the "page-like" sites and trying to shoehorn it into a modern app-like experience is wrong.

>> Your demo is very welcome, but it only solves a narrow part of the problem AND
>> it uses a complex library. As you've said it doesn't scroll properly neither it works
>> as expected on desktop browsers.

hammer.js is only ~5kb and it includes lots of non-pinch related things. I'm confident someone could (likely already has) write a minimal pinch-zoom recognizer. The scrolling/desktop issues were my own laziness, I've updated http://bokan.ca/demo/pinch-zoom-reflow.html to fix this.

>> Again, in every other browser I can do that reflow-to-viewport with 10-20 lines of JS.

I'm skeptical this can work well. For starters, how can you tell the user has pinched? Mobile IE used to send an (async) resize event, but as far as I can tell, Safari and Firefox don't. Even if they did, the zoom happens on a separate thread - there's no timing guarantee. I just converted my example to the "reflow to innerWidth" model: http://bokan.ca/demo/pinch-zoom-reflow-safari.html. Safari will only resize when the top controls show and hide or on rotation. I suppose you could poll with a setTimeout or raf but that's considered very bad practice (you're draining your user's battery).

In contrast, note how my example page works pretty much the same in all the browsers (I've tried Chrome/Firefox/Safari) without any special cases (Safari loses fling, I haven't looked into it, I think its some separate issue regarding TouchEvents...ah, the web...). Additionally, you have far more control over how the zoom happens. In my example I can reflow in real time as the user pinches - you can't do that with the "status quo". I could also reflow only once the user finishes the pinch. *I* get to choose.

>> And just to drive the point further, the link you've quoted is very supportive of the existing status-quo, which you've deviated from

Obviously, I disagree with the author on that point. :)

Comment 25 Deleted

Comment 26 by joi@chromium.org, Feb 8 2016

This bug can break communication software, such as screen sharing software, where you might use knowledge of the viewport to communicate back to the presenter which bit of what's being presented the viewer is looking at. A concrete example is my startup, CrankWheel, which is a Chrome extension that lets you present, and a couple of different HTML/JS-based clients that let you view. If you need to see it in action to reproduce, it's free to use at crankwheel.com; just present something, view it on your mobile, pinch to zoom, and on every browser except Chrome 48 you will see on the presenter side when the viewer zooms in.
Hi joi@,

That sounds like a valid (if niche) use case and something we could support with a new API. From a quick glance, it looks like you do this through an extension? In that case, does it work on Android? (since Chrome has no extension support on Android). In any case, I'll keep that in mind.
@bokan, is devtools protocol useful here? Seems like this applies to
webdriver-style testing...
Thanks, that's a good point - I haven't looked into it. I'll investigate if we have enough there or if it makes sense to add this information there.

Comment 30 by joi@chromium.org, Feb 9 2016

Cc: jam@chromium.org ben@chromium.org
Thanks for the response @bokan. The presenter end of CrankWheel is an extension, the viewer end (which needs window.innerWidth et al) is just a plain old web page which works on practically all browsers, including on Android. But it's easy to imagine scenarios where both ends could be plain old web pages, e.g. video conferencing or screen sharing based on WebRTC, and transmitting knowledge of what exactly the other party is seeing on their screen could be useful in such an app.

IMHO, it would be great to roll back this change and make Chrome behave the same as other browsers, since Chrome's behavior now is different from other browsers (even if there is no standard except a de facto one) and therefore this is currently fragmenting the web platform. Even if there are approaches to work around this as suggested in #14, those approaches would (at least in our case) be Chrome-specific. Better to stay compatible until things are standardized.
> IMHO, it would be great to roll back this change and make Chrome behave the same as other browsers, since Chrome's behavior now is different from other browsers

I disagree.

The argument you made is a common way web folks think about things, and for that reason your argument has been made many times before and we've even rolled back this change before.  But in this case, we need to weigh it against the counter-principle that bokan@'s change also makes us much more compatible and consistent with *desktop Chrome*, even though it diverges from the (internally inconsistent, unusable for many use cases) behavior of other mobile web browsers.  It successfully fixed many bugs particularly on desktop-designed websites.  And another principle we follow is that we don't diverge core behavior like this based on the presence of <meta viewport> tag.

We successfully shipped this to stable channel with minimal observed breakage except a few complaints here on the bug, this proves it's satisfactorily web-compatible.  I support letting it stick.
FWIW, Edge (which has the same PZ model as Chrome) engineers have stated they'll follow suit if our experience with this is good and Safari/Firefox (which have a different PZ model) have at least shown some curiosity in moving to our PZ model. Our goal is to converge all the browsers on a more rational model.

There's a users vs. developers trade off here. Not withstanding some overlap in implementation details, browser pinch-zoom is already sufficiently difficult/impossible to build around reliably that I think the argument for improving user experience is the stronger one.
Hi, I'd like to add my thoughts this conversation.  My company creates custom widget solutions (js/css/html snippets) for e-commerce clients, and in order to facilitate development in a mobile domain we have created a custom script that functions exactly as outlined in the 'fifth positioning' proposal (position: device-fixed) mentioned earlier in this discussion thread:

http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html

To be honest I was surprised to read that proposal since we developed our script independently, having never read the document, and it describes exactly the solution we have built!  But I'm happy to see someone is aligned with our thoughts here. ;)

Anyhow, the script we built allows us to keep whatever elements we need fixed to the device's viewport regardless of zoom or scroll.  In order to achieve this we have to set the required elements to 'absolute' and we use innerWidth/outerWidth/innerHeight/outerHeight to calculate the zoom ratio in order to know how much to scale the element in question.  As the user zooms in, we scale down the element accordingly, and as the user scrolls along the x/y axis we re-position the element so that it is always in the same x/y position relative to the edge of your device's screen.  The downside to doing this in javascript (vs a native position:device-fixed implementation as proposed) is that we can't do this in a truly 'fixed' fashion in real time, so we wait for the user to lift their finger(s) off the screen before smoothly translating/scaling the element to the new position.  It works quite well and was an excellent solution for our clients that don't have zoom-locked sites (which is still quite a substantial number).

The problem now however is that innerHeight/Width no longer returns the results we require to measure zoom and screen positioning.  As a result we are stuck with widgets that overflow the screen when the user is zoomed on a page.  This is a big problem for us and without having access to the screen positioning values we previously had there is no good solution left to us for implementing our product in Chrome.

In our case we wouldn't need access to these screen dimensions (or our re-sizing script at all) if a 'position:device-fixed' property existed as a natively implemented positioning system.  But even if that was to be implemented I would still vocally oppose this change to innerHeight/innerWidth as it assumes somebody would never want access to those values.  I think it's a bit shortsighted.  There are likely a number of possible situations where having this information accessible will be useful to a developer especially as mobile web development continues to mature.  Expecting all sites to use zoom-locked layouts (while I don't necessarily disagree with this design habit on principle) is a bit presumptuous, and there will always be edge-case situations in which a user is going to want to zoom in when using touch-enabled devices or smaller screens.  Perhaps it's an issue of poor eyesight in aging populations, or wanting to see details in an image while viewing on a phone.  To assume these are not viable use cases that an end user would ever desire is short-sighted.  If a developer wants to use a fixed mobile layout for their site that never zooms, that's totally their prerogative, but so too should it be their choice to instead develop one that uses dynamic reflow, or dare I say zoom navigation.

Obviously I have some personal motivation for reverting this change as this surprise negatively affects our product.  But in general I'm not a big fan of forcing adoption of design practices which seems to be the primary motivation for this change.

I also strongly support the position:device-fixed proposal as I think it's an elegant solution for dealing with content on zoomed screens that is meant to be displayed within viewport bounds.

I realize this is a bit of a long post, but I appreciate all of your time in reading this and your consideration of my ideas presented within.  Thanks!

Comment 34 by bokan@chromium.org, Feb 10 2016

Hi there,

Unfortunately, there's no way to tell apart your use case from others on the web that *hurt* user experience under pinch zoom. For example, it's a very common pattern to position menus using window.scrollX and getClientBoundingRect. In the old model, when a user pinch zooms in on the page the menus would appear in the wrong place or completely off screen.

We're not advocating for "zoom-locked" layouts. Rather, when the user does pinch-zoom, we don't want the page to respond to that - at least not by reusing APIs that were designed before pinch-zoom came along since that frequently does the wrong thing (e.g. position: fixed making some pages unusable with PZ in Safari/Firefox). The accessibility issues you allude to are one of the strongest cases for doing this; if a user needs to zoom into see something on the page, having the page react or change in some way will frequently make this more difficult (for a user with poor eye-sight, what if they can't read your widget and want to make it bigger?). We're thinking of the built-in pinch-zoom as a feature of the browser and not of the web platform. More like the Windows screen magnifier.

By the way, you can star issue 542770 to get updates on and express interest in position:device-fixed. We're looking to implement that soon, but even there, we're being a little cautious. If device-fixed suddenly proliferated across the web it could hurt accessibility as users would lose the ability to zoom in on the fixed content.

Comment 35 by tay...@granify.com, Feb 10 2016

Thanks for your response.  I see what you're saying about accessibility for non-zooming material.  In the case of our widgets since they don't re-scale/position themselves until the user stops touching the device's screen it's not as much of an issue.  Regardless, for our situation having certain elements stay fixed to device screen boundaries is much better than the alternative of having things like modals where the close button has been pushed off screen.  Unfortunately we can't use the solution we developed for that in Chrome anymore.  It's nice having the control to decide which elements should be able to zoom for user accessibility, and which ones shouldn't (like in my example where allowing zooming would push required UI features off screen; it's super important to us to avoid exposing our users to that kind of frustration).

Anyway, I appreciate your response and I'll definitely star issue 542770 as it would solve the issues that made development of our mobile-resizing component necessary.  Thanks!

Comment 36 by pp.k...@gmail.com, Feb 11 2016

I strongly object to this change. I wrote a blog post detailing my problems at http://www.quirksmode.org/blog/archives/2016/02/chrome_change_b.html

Briefly summarised:

1) This change breaks the web. ALL other browsers support window.innerWidth/Height as exposing the visual viewport dimensions.
2) Any problems with window.innerWidth are very easy to solve by replacing it with document.documentElement.clientWidth
3) This change closes off innovation with regard to zoom-based layouts.

The blog post treats each of these counterarguments in more detail.

Comment 37 by powrs...@gmail.com, Feb 11 2016

I just wanted to respond to one point:

> zooming in doesn't cause the page to reflow in any way so the page requires horizontal scrolling.

This is not the case in all Chromium-based browsers. Opera (and others that ppk could rattle off) does reflow text when the visual viewport changes.

In regards to accessibility, I feel that this truly is an important point that should have research made before it is changed and not just be something well-intended developers make a change that could end up causing harm. Has anyone actually reached out to accessibility advocates and those that make accessibility software what they think or their advice on this? The fact that I posted ppk's blog post in #a11ySlackers and it got Steve Faulkner's attention makes me think this has not been the case.

Comment 38 by bokan@chromium.org, Feb 11 2016

Re #36, a few counter points:

>> "Building an app that responds to pinch zoom is actually quite possible: poll the visual viewport size every 100 milliseconds, and change your layout
>> when the dimensions turn out to have changed"

This is precisely why I think this is the right move. I'm all for people using zooming layouts, but the toolbox we've given to developers doesn't allow them to build these apps in a user friendly way. If this kind of pattern caught on and 100 ms polling (for example) proliferated across the web it would be bad for the web in the long run.

Also, on ChromeOS (and potentially on Android, issue 404315), the on-screen keyboard resizes the visual viewport rather than the layout viewport. Assuming innerWidth/Height indicates zoom is wrong and would make future innovation around viewports more difficult.

>> "...I don’t doubt that this is happening in practice, but I’d say it’s the web developers’ fault for not testing their sites on mobile at all"

>> "That means it has worked the way it does in ALL browsers for over four years, and it’s only now that problems were discovered. That’s a bit late."

Pinch-zoom isn't restricted to mobile any more though. We changed the meaning of innerWidth back when mobile browsers were introduced and *that's* where we broke backwards compatibility. This has been broken all along, it's a more visible problem now as touchscreens are making their way to desktop browsers and users pinch on content not designed for phones. We gave innerWidth a different meaning between mobile and desktop and now we have to reconcile them. The fact that it hasn't been useful on mobile until now lets us do that and, where needed, replace it with a new API.

To emphasize this: I haven't seen any bug reports from users complaining a page is broken because of this change.

>> "What I DO know, though, is that the Chrome team made an entire line of inquiry impossible"

Pinch-zooming interfaces are alive and well on the web - see any mapping product on the Web (Google or Bing Maps). Note how *none* have used the native browser pinch-zoom implementation (in Bing's case, even though IE built all sorts of custom zooming functionality: -ms-content-zooming). And yet they've built impressive pinch-zoom interfaces. It's a bit more work, but to say that innovation is impossible is demonstrably false.

Comment 39 by pp.k...@gmail.com, Feb 11 2016

>This is precisely why I think this is the right move.

Web devs can do all kinds of atrocious things. Will you remove all functionalities that empower those things? Then browsers would support little more than basic HTML. 

To me, this argument is a non-sequitur. Also, it seems to me you're being over-protective, which in the long run is indistinguishable from pushing the web in the direction Google thinks best. I'm not saying you're doing that right now, but in the long run that could become a problem, and it's best to avoid going there in the first place.

>Also, on ChromeOS (and potentially on Android, issue 404315), the on-screen keyboard resizes the visual viewport rather than the layout viewport.

True, but you can easily detect that through the aspect ratio and/or the fact that innerWidth doesn't change; just innerHeight. If the aspect ratio is the same as the device, the user zoomed; if it's different, the keyboard (or toolbar) caused a visual viewport change. 

Again, this is not an argument for removing the visual viewport dimensions. If anything, you made an excellent argument against it. Sometimes it might be very useful to know if the user has the keyboard open.

>Pinch-zooming interfaces are alive and well on the web - see any mapping product on the Web (Google or Bing Maps).

So you want everybody to write customised scripts and stuff to emulate a simple native browser function? To me, that way lies madness. We already have most of the tools we need to create such interfaces (except for a zoom event; we need that!), so why bother writing a custom interface?

(That last question was semi-real, by the way, and not merely rhetorical. If there's  important functionality missing right now, I'd like to know about it - and it would be an excellent candidate for inclusion in the new API.)

Finally, I saw no answer to the charge that this change breaks the web.

Comment 40 by bokan@chromium.org, Feb 11 2016

Re #37,

Regarding reflow - you're correct, I believe Opera does this. That said, this change doesn't affect them or us in that regard.

Regarding accessibility, my intuition is this change is good for accessibility since 1) Pages won't change/do crazy things when users zoom in and 2) Fixes pages that break under pinch-zoom

That said, I'm not an accessibility expert so I'm all ears to hear counter examples and criticisms.

Comment 41 by bokan@chromium.org, Feb 11 2016

>> Web devs can do all kinds of atrocious things. Will you remove all functionalities that empower those things? Then browsers
>> would support little more than basic HTML.

And we do support those things once they're out there. IMO, in this case we have a feature that can only be used poorly and isn't being used - it's a pragmatic choice to replace it with something before our hands are tied.
 
>> Also, it seems to me you're being over-protective, which in the long run is indistinguishable from pushing the web in the direction
>> Google thinks best.

I agree we need to be careful and we don't want to be overly paternalistic. But at the same time, if we wait for consensus on every detail we won't make any progress and the web will stagnate. We've made these changes in discussion with the Edge team and they've been supportive. Safari and Firefox have a more web-visible model of pinch-zoom but we've have discussions with them and, at the lest, they didn't think this was a terrible idea (Firefox and (I've heard) Safari have expressed curiosity in following our pinch-zoom model - I don't think PZ is a priority for either though). We're trying to incrementally evolve pinch-zoom in a more rational direction to a place where it's plausible other vendors could one day follow.

>> Again, this is not an argument for removing the visual viewport dimensions. If anything, you made an excellent argument against it.
>> Sometimes it might be very useful to know if the user has the keyboard open.

I agree, but I'm arguing that innerWidth/Height and other existing properties are the wrong API for this and will lead to more pain down the road. I'd like to fix this before we start hoisting more new features on the visual viewport and it becomes too big a mess to clean up. I think the introduction of mobile browsers overloaded the meaning of many existing APIs where new ones should have been added. We're now paying down that technical debt.

>> So you want everybody to write customised scripts and stuff to emulate a simple native browser function? To me, that way lies madness. We already have 
>> most of the tools we need to create such interfaces (except for a zoom event; we need that!), so why bother writing a custom interface.
>> ...if there's  important functionality missing right now, I'd like to know about it...

For starters, all browsers implement pinch-zoom in the non-main thread so, at best, the UX will be shoddy as the JS thread and compositor will sync at unpredictable times. Furthermore, browser pinch-zoom is an all-or-nothing effect and most frequently authors want to keep at least some of the interface unzoomed. So now we're back writing customized scripts anyway. To make any non trivial zooming experience, even today, requires plenty of scripting and results in a mediocre experience at best. I would be happy if we added a zoom event btw (The details predate me but I've heard the area in general is plagued by non-technical obstacles...) but even if we did that, you'd still be scaling your UI by handling that event and applying CSS scale so you've really just replaced the TouchEvents portion of what we already have (which I think would be a great change anyway).

In contrast, TouchEvents and CSS Transforms aren't that complicated and let you build a very nice experience. I would rather see a PZ library written on top of these (so not everyone is writing it themselves) that allow authors to build the exact experience they want. This is in line with the extensible web manifesto (https://www.w3.org/community/nextweb/2013/06/11/the-extensible-web-manifesto/), the browser gives authors the low-level primitives which the web community can innovate on top of. Microsoft added a number of additions to pinch-zoom (position:-ms-device-fixed, -ms-content-zooming, etc). These are nice, but they're syntatcic sugar on top of what you can do with the primitives. If the web community invents some useful additions using the primitives, we can adopt them into the browser and provide that sugar. But browsers move too slowly to keep adding these knobs on high level features and authors will work around the limitations (often poorly) anyway.

>> Finally, I saw no answer to the charge that this change breaks the web.

Virtually any change "breaks the web" so browsers have to make pragmatic choices about cost/benefit. Chrome has the policy that features with < 0.03% of page load usage (https://www.chromestatus.com/metrics/css/popularity) are candidates for removal. Unfortunately, there was no way to accurately measure the impact of this change. Given that we haven't had any end-user complaints yet (it's still early so maybe time will tell, but when a change affects users, we hear about it!) I think we got the cost/benefit analysis correct.

Comment 42 by mihai...@gmail.com, Feb 11 2016

Just to clarify — a practical approximation for resize event can be trivially done by listening to key/mouse/touch at document level and comparing current/last sizes. No timers, all kosher.

My app works in IE6, old Blackberry and Presto — in addition to modern browsers. It takes ~15 LoC for pinch-zoom support.

Comment 43 by mihai...@gmail.com, Feb 11 2016

What is a material downside in holding this change off until that neat touch/scale refactoring is finished?

With all due respect, it's hard to buy 'let's do it now before too late' argument for something been around for many years. What's the sudden rush?

But anyways, can you put this new behaviour behind a flag for now? That's the standard way — so keep it off with a flag to enable. 

It's clear you have something big amd cool in your mind, but don't let it sizzle with badly timed rollout.




Comment 44 by tay...@granify.com, Feb 11 2016

I 100% agree that there should be a better solution for handling zoom, but until we have that solution it would be nice if we could keep the old functionality in the meantime instead of being stuck with nothing.

Comment 45 by pp.k...@gmail.com, Feb 12 2016

>And we do support those things once they're out there. IMO, in this case we have a feature that can only be used poorly and isn't being used - it's a pragmatic choice to replace it with something before our hands are tied.

1) window.innerWidth/Height is out there to a remarkable degree.
2) Although I take your word that it's hardly being used, I fundamentally disagree with the statement that it can only be used poorly. This thread as well as my blog post contain examples of interesting, non-poor use of the visual viewport dimensions.
 
>> Again, this is not an argument for removing the visual viewport dimensions. If anything, you made an excellent argument against it.
>> Sometimes it might be very useful to know if the user has the keyboard open.

>I agree, but I'm arguing that innerWidth/Height and other existing properties are the wrong API for this and will lead to more pain down the road. 

Backward compatibility. It's the API we have.

I'm curious what the new API will bring, and I totally agree that this is the way to go forward, but we can't simply ignore backward compatibility.

>> ...if there's  important functionality missing right now, I'd like to know about it...

>For starters, all browsers implement pinch-zoom in the non-main thread so, at best, the UX will be shoddy as the JS thread and compositor will sync at unpredictable times. 

As far as I can see the only true solution would be to execute pinch zoom in the main thread, but that would have a lot of unintended side effects as well. Or are you thinking of allowing a quick script to run during zooming, based on a zoom event handler or something?

Anyway, this is probably an over-simplistic solution and I agree we have a serious problem here.

>Furthermore, browser pinch-zoom is an all-or-nothing effect and most frequently authors want to keep at least some of the interface unzoomed. 

That's true. As far as I'm concerned the solution is position: device-fixed, as I proposed years ago: http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html

IE11 implemented this as a test; though it still had horrible performance when I last looked. (Not tested in Edge yet.) 

I also wrote a test case (horrid performance) that, oh irony, doesn't work in Chrome any more because it depends on the dimensions of the visual viewport: http://www.quirksmode.org/m/tests/devicefixed.html

>So now we're back writing customized scripts anyway. To make any non trivial zooming experience, even today, requires plenty of scripting and results in a mediocre experience at best. 

and

>I would be happy if we added a zoom event btw (The details predate me but I've heard the area in general is plagued by non-technical obstacles...) but even if we did that, you'd still be scaling your UI by handling that event and applying CSS scale so you've really just replaced the TouchEvents portion of what we already have (which I think would be a great change anyway).

I think you're taking too many steps here. A zoom event would merely inform the script that the user has zoomed; that's it. It all depends on what the web developer does with this information.

You say that web devs WILL do terrible things no matter what. I disagree: I think we could also write light, lithe scripts that do something useful in a non-intrusive way. 

I don't doubt that at Google you see more of the ugly, kludgy, let's-throw-in-another-library-and-to-hell-with-performance side of web dev than I do, but there are people out there who are aware of the limitations and want to experiment with zoom-based features that are not predicated on complex scripts. You take away that opportunity. I do not like that.

>> Finally, I saw no answer to the charge that this change breaks the web.

>Virtually any change "breaks the web" so browsers have to make pragmatic choices about cost/benefit. Chrome has the policy that features with < 0.03% of page load usage (https://www.chromestatus.com/metrics/css/popularity) are candidates for removal. Unfortunately, there was no way to accurately measure the impact of this change. Given that we haven't had any end-user complaints yet (it's still early so maybe time will tell, but when a change affects users, we hear about it!) I think we got the cost/benefit analysis correct.

Fair point about cost/benefit in general, but I fail to see what would constitute the cost of keeping innerWidth alive.

Comment 46 by tay...@granify.com, Feb 12 2016

"You take away that opportunity. I do not like that."

Yeah, that's the part that kind of rubs me the wrong way too.  We independently developed a script that does almost exactly what you were trying to achieve here:

http://www.quirksmode.org/m/tests/devicefixed.html

But our script is broken on Chrome now too (thanks to these changes), and there's no other good solution for ensuring required UI elements stay available on a zoomed screen.  If there WAS another solution (ie: position:device-fixed) I'd happily adopt it, but currently there is not and now the ability for us to implement our own interim solution has been taken away with these latest changes.  

It's definitely frustrating since we put a lot of work into building our script and were proud to be taking a lead in pioneering good, practical, mobile display solutions.  It continues to work nicely in iOS Safari but it's unfortunate that this is no longer the case for chrome. :(
I strongly support @#33 tay...@granify.com's point of view.
There should definitively be a way for web developers to read the position and dimension of the visual viewport from JavaScript.

I totally agree that using window.innerWidth for that purpose has never been a good solution. But changing the browser behaviour without replacement breaks quite alot of web apps relying on that (including a couple of web apps I created over the past years).

"position: device-fixed" would surely be handy in some cases, but it would not be sufficient in a couple of other cases.
A new API to read the position and dimension of the visual viewport would be very nice.
I don't mind spending a couple of days changing the code of my apps, but preventing web developers from getting the visual viewport information in general would be a very bad idea from my point of view.
Agree with the comments above.

Would very much like to receive a transitional phase-out instead of an abrupt cutoff with no runway.

Furthermore, Chrome is capable of throwing Yellow/Red deprecated warning... can that be an option?

Thanks!
I would like to add one of the use cases where knowing the visual viewport position and dimension is essential. This is about images.

Think of a web page showing multiple (scientific) images. The requirement is to show all images inside the visual view port at exactly the display's pixel ratio (without the browser scaling up or down images). 
Loading the images on start at high resolution is not an option for bandwidth and performance reasons.
Neither is showing the images at about the display's pixel ratio or at a lower resolutions (blurry images).

This used to work fine before this change and it does not affect the page layout or usability at all.
I am of course aware that this is not something everybody needs, but without access to the visual viewport size and position it is impossible to achieve something like that.
So please consider at least adding an API to get the visual viewport size and dimension.

Comment 50 by bokan@chromium.org, Feb 12 2016

Re #45,

>> 2) Although I take your word that it's hardly being used, I fundamentally disagree with the statement that it can only be used
>> poorly. This thread as well as my blog post contain examples of interesting, non-poor use of the visual viewport dimensions.

I meant trying to rearrange the content in response to a pinch zoom using innerWidth/scrollX can only lead to a poor UX. Anyway, you're right, you and others here have presented some valid uses. I'm not even against letting people do crazy/ugly things but the lack of consistency and breakage caused by this outweigh its usefulness.

That said, I may have underestimated how much developers were relying (and passionate) on this. I'm less opposed to putting this back behind a flag until we ship a replacement API. Since this had already hit stable, we probably wouldn't ship an update to this in M50 but I expect would could make M51. I'm not committing to  yet, but I'll deliberate over the next few days taking the feedback here into consideration. Note though, I do still support making innerWidth/Height, scrollX/Y relate to the layout viewport, we may just want a better transition path.
 
>> As far as I can see the only true solution would be to execute pinch zoom in the main thread, but that would have a lot of
>> unintended side effects as well. Or are you thinking of allowing a quick script to run during zooming, based on a zoom event 
>> handler or something?

Main thread pinch-zoom is essentially the TouchEvents + CSS Transform solution I've previously mentioned. It's really the only way to get a zooming experience that's customized and relies on real-time updates in script.

If we were to add a zoom event it would certainly be an asynchronous update - much like how scroll events are updated asynchronously when we're scrolling off the JS thread. That would be useful for cases where a delay doesn't affect the UX (e.g. your example about tracking how much users zoom) but you still wouldn't want to do something like implement position: device-fixed like that.

>> That's true. As far as I'm concerned the solution is position: device-fixed, as I proposed years ago:
>> http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html

Agreed, I'm supportive of position: device-fixed and we're currently working on adding it to Chrome.

Comment 51 by tay...@granify.com, Feb 12 2016

I would be in support of re-implementing it behind a flag for now.  I'm also very excited about "position: device-fixed" being seriously looked into. :)

Thanks for your consideration of our feedback!

Comment 52 by bokan@chromium.org, Feb 12 2016

Cc: bokan@chromium.org
 Issue 584909  has been merged into this issue.

Comment 53 by juw...@gmail.com, Feb 12 2016

Just idiot question from me.
What is the purpose of window.innerWidth/innerHeight on mobile devices after newest change if before it was there to measure zoom states like on all other devices, but for what purpose it should be used now after breaking old behaviour?
In fact, after last Chrome update these variables have zero valueable information where these could be reused in that broken state like they are now..
Beloved Chrome developers, before releasing such broken things, please use your brain!
I am angry developer, who is running mad. It was enought for me you broke position:fixed, but now you did your best and broke last working way to recognize visible viewport.
I do not find smart words for you guys. 

Comment 54 by arce...@gmail.com, Feb 13 2016

I fully trust you that these features might were being miss-used, but in any case i see an improvement here, as I am working in a page that displays pictures in a container positioned relative to visual viewport.
As ppk has stated, getting layout width was already possible with document.documentElement.clientWidth, so now we are stuck with two copies of this functionality, and none for the visual viewport.
I can agree that this is an advancing step, but leaving no support for this functionality is hardly a good move.
As stated, and while you claim that usage is <0.03%, you've recognized there are some well made points here, and i'd like to adhere to them.
While we expect for a new API and hopefully in the position: device-fixed, I do agree (and beg) for a return of a way to calculate visual viewport.

Comment 55 by juw...@gmail.com, Feb 14 2016

(Chrome change breaks the visual viewport)
No this link
http://www.quirksmode.org/blog/archives/2016/02/chrome_change_b.html
got very wide publicity, just found it on one news portal.
Also Chrome developers, you see, the things you broke did not stay unnoticed in web community.
I feel removing these properties completely would have been a better approach than changing their meaning / output.

Detecting that the properties are gone is actually feasible. Whereas developers will probably have to hard-code user agent strings for Chrome 48, 49, 50 (and so on until this is reverted) for "detecting" that the meaning / output of these values is incorrect.

Comment 57 by juw...@gmail.com, Feb 15 2016

No, removing/changing anything is bad idea anyway, because the pages that depend on these values would cause highly Javascript error, if removed, and so affect many pages without users knowledge about. 
We developers try our best to make pages looking in all browsers similar, and if one browser breaks something that worked before without letting the chance to simulate the old behaviour, our anger is of course preprogrammed in such case.
In my opinion the best what Chrome developers can do.

1. Revert old behaviour back, I do not care about cases that need these variables in their new meaning of layout viewport. (so far I understand after changing position:fixed to layout viewport {i dislike that change too} it is possible to simulate anyway this layout viewport behaviour)
In my opinion, I have big doubts that other browsers (FireFox Mobile, Safari iOS, Microsoft IE mobile) would follow Chrome and break window.innerWidth/Height/pageX(Y)Offset too. I mean, you are not Gods that they would do anything after you.

2. Create new API for visual viewport.
In my opinion that was anyway absolutely crazy idiot idea to play pioneers and break things that worked fine on all browsers (except now Chrome).
(as example on my page I use virtual keyboard that resizes and repositions it self according to zoom pinch to simulate the behaviour of native keyboard)
Now this behaviour is completely broken thanks to you guys..
And what should I do now when customers ask me, hey, your virtual keyboard looks broken on Chrome. I can not explain to each customer, the Chrome developers broke it..
PS: if I would be your chief, I would fire out every developer without regret who was jointly responsible for breaking old visual viewport behaviour, so much I counted on this feature..

Comment 58 by pp.k...@gmail.com, Feb 15 2016


>I meant trying to rearrange the content in response to a pinch zoom using innerWidth/scrollX can only lead to a poor UX. Anyway, you're right, you and others here have presented some valid uses. I'm not even against letting people do crazy/ugly things but the lack of consistency and breakage caused by this outweigh its usefulness.

There is no lack of consistency: innerWidth is the visual viewport. As to breakage: bad web devs will do bad things, and, as I said before, I think Chrome has gone somewhat too far here in attempting to avoid breakage.

You can always publish an advisory to replace window.innerWidth with document.documentElement.clientWidth in cases of bad breakage; that will solve the problem for now. (Maybe d.dE.cW + 16 if scrollbars are involved; but yes, it is really that simple.)

>That said, I may have underestimated how much developers were relying (and passionate) on this. I'm less opposed to putting this back behind a flag until we ship a replacement API. 

Thanks for reconsidering; this is really very helpful.

However, I do not fully understand the flag comment. If it's behind a flag you still break compatibility with other browsers and we still can't use it for actual projects. Thus its actual usefulness will still be zero, and innovation and research will still be stifled. Or did you mean something else?

As far as I'm concerned the old situation - innerWidth exposes visual viewport and is generally available - should be restored pending the arrival of the new API. Once the API is there behind a flag we'll take it on a test ride, and eventually it will be de-flagged (if that's the proper terminology). 

By that time I think I will defend the viewpoint that, despite the new API, innerWidth should remain in place as an alias so as to ensure backward compatibility. But who knows, maybe the new API will make that unnecessary. Can't say until I see it.

>Since this had already hit stable, we probably wouldn't ship an update to this in M50 but I expect would could make M51. I'm not committing to  yet, but I'll deliberate over the next few days taking the feedback here into consideration. Note though, I do still support making innerWidth/Height, scrollX/Y relate to the layout viewport, we may just want a better transition path.

I understand these changes won't be made in a day. As long as there is a reasonably quick path forward, I'm happy. M51 sounds fair enough; it's something along the lines of a three months wait, right? We can survive that.

scrollX/Y: do whatever you like. I thought they were already relative to the layout viewport, and I can't figure out what you mean when you say it's relative to the visual viewport, so my testing must be way off here and I don't have the right to form an opinion.

>If we were to add a zoom event it would certainly be an asynchronous update - much like how scroll events are updated asynchronously when we're scrolling off the JS thread. That would be useful for cases where a delay doesn't affect the UX (e.g. your example about tracking how much users zoom) but you still wouldn't want to do something like implement position: device-fixed like that.

>I'm supportive of position: device-fixed and we're currently working on adding it to Chrome.

I fully agree a zoom event should be asynchronous like a resize event. Anything else would lead to very bad performance indeed. And device-fixed should be synchronous (if at all possible) and implemented separately from the zoom event, I also agree. Very nice that you're looking into it; I think it will solve real-world problems mobile web devs have.

Anyway, thanks again for reconsidering,

Comment 59 by jpet...@gmail.com, Feb 15 2016

In regards to: "Modern web pages/apps should be designed such that they don't need pinch zoom. For more complicated cases (e.g. Google Maps), the app should build its own pinch-zoom mechanism using CSS transforms and TouchEvents. Building on top of browser pinch-zoom is futile since its so poorly supported (the experience will be terrible due to threaded scrolling) and interop (no two browsers work alike in this area)."

I have a pinch-zoom-reliant interface, and have spent 2-3 days trying to replicate the browser's native pinch-zoom as you suggest. I could get nowhere near the buttery-smoothness and predictability of the native pinch-zoom functionality (I got it kinda-okay on desktop, but the perf was unusable on tablet/phone).

I'd definitely prefer to build on top of the amazing pinch-zoom work Chrome & other browser vendors have done rather than try to roll my own.

Comment 60 by bokan@chromium.org, Feb 16 2016

> There is no lack of consistency: innerWidth is the visual viewport.

The inconsistency is that there was no concept of a visual viewport on desktops until recently so innerWidth was the layout viewport on desktops. Now that touchscreens are coming to desktops we've basically changed what innerWidth means.

> You can always publish an advisory to replace window.innerWidth with document.documentElement.clientWidth in cases of bad breakage;

Unfortunately, that's not likely to move the needle much. Devs will fix things when they appear broken and given that most desktops don't have touchscreens or need to pinch-zoom the issue is unlikely to get much attention. That's not even counting the long tail of content that won't get any updates...

> However, I do not fully understand the flag comment.

If *this* change goes back behind a flag, only users who explicitly turn on the flag get that behaviour so the practical effect is that Chrome would revert to the old model. (A tiny fraction of users ever turns on any flags).

> I understand these changes won't be made in a day. As long as there is a reasonably quick path forward, I'm happy. M51 sounds fair
> enough; it's something along the lines of a three months wait, right? We can survive that.

I misspoke, I could plausibly still revert this in M49, M50 in the worst case, so a couple of weeks most likely.

> scrollX/Y: do whatever you like. I thought they were already relative to the layout viewport

No, they were the position of the visual viewport with respect to the document origin. Most of the breakages were actually caused by this pair rather than innerWidth/Height but it would be excessively strange if window.scrollX/Y was the position of the layout viewport but window.innerWidth/Height was the dimensions of the visual viewport. Any use case in this bug that tries to keep things in the visual viewport needs this pair as well as innerWidth/Height to do the positioning properly.

Comment 61 by pp.k...@gmail.com, Feb 16 2016

>The inconsistency is that there was no concept of a visual viewport on desktops until recently so innerWidth was the layout viewport on desktops. 

If six years ago is "recently", yes, then this is a recent change. I started seriously studying the viewports at the end of 2009, and by that time Apple, Nokia, and BlackBerry already supported innerWidth, even in their old browsers.

>Now that touchscreens are coming to desktops we've basically changed what innerWidth means.

Yes, touchscreens on desktop computers are going to strain our viewports to the limit  - especially when they support both pinch zoom and page zoom. I'm currently thinking about these issues, and hope to come with a recommendation.

>> You can always publish an advisory to replace window.innerWidth with document.documentElement.clientWidth in cases of bad breakage;

>Unfortunately, that's not likely to move the needle much. Devs will fix things when they appear broken and given that most desktops don't have touchscreens or need to pinch-zoom the issue is unlikely to get much attention. That's not even counting the long tail of content that won't get any updates...

True, but your responsibility stops somewhere. And putting this trick online will help in a few cases.

>> However, I do not fully understand the flag comment.

>If *this* change goes back behind a flag, only users who explicitly turn on the flag get that behaviour so the practical effect is that Chrome would revert to the old model. (A tiny fraction of users ever turns on any flags).

Oh great, so innerWidth will be restored. Thanks so much.

>I misspoke, I could plausibly still revert this in M49, M50 in the worst case, so a couple of weeks most likely.

The sooner the better, obviously. Thanks!

>> scrollX/Y: do whatever you like. I thought they were already relative to the layout viewport

>No, they were the position of the visual viewport with respect to the document origin. 

It took me a long time, but I now finally understand why it's relative to the visual viewport. And although I don't have any firm ideas on whether this is good or bad, what I do know is that eventually we're going to need scrolling offsets of both viewports relative to the document. With your proposed change there would be no way of finding the current position of the visual viewport, and that, too, is something we'll need when working on anything zoom-based.

>Most of the breakages were actually caused by this pair rather than innerWidth/Height but it would be excessively strange if window.scrollX/Y was the position of the layout viewport but window.innerWidth/Height was the dimensions of the visual viewport. Any use case in this bug that tries to keep things in the visual viewport needs this pair as well as innerWidth/Height to do the positioning properly.

Question: is this breakage very specifically caused by web devs using window.scrollX/Y? As opposed to window.pageX/YOffset, which is hardly being used? 

If so, we could solve your issues and get what we need at the same time by making scrollX/Y relative to the layout viewport and pageX/YOffset relative to the visual viewport. 

I admit that this is not logical for web devs without mobile experience, but I think we should also weigh the interests of mobile web developers, who do need the scrolling offset of the visual viewport.

Comment 62 by bokan@chromium.org, Feb 16 2016

> Question: is this breakage very specifically caused by web devs using window.scrollX/Y? As opposed to window.pageX/YOffset,
> which is hardly being used? 
>
> If so, we could solve your issues and get what we need at the same time by making scrollX/Y relative to the layout viewport
> and pageX/YOffset relative to the visual viewport.

The most common problem I saw (though it's not limited to this) was positioning popup menus, e.g. when a button is clicked, by getting the button's rect via getBoundingClientRect (layout viewport relative) and then positioning a menu using position: absolute and converting to document coordinates by adding window.scrollX/Y.

Yes, we could solve the immediate problem by making pageX/YOffset different but I'm afraid of repeating this situation. scrollX is defined to be equivalent to pageXOffset so changing that may cause other surprises. In my experience, the model of shipping a brand new (properly named) API, giving developers an appropriate runway to make changes, and then deprecating the old feature has worked much better and I think can work well in this case. Additionally, it has the very real benefit of being able to do feature detection: |if (window.visualViewport) window.visualViewport.getBoundingRect()| ?

Comment 63 by pp.k...@gmail.com, Feb 16 2016

>> Question: is this breakage very specifically caused by web devs using window.scrollX/Y? As opposed to window.pageX/YOffset,
>> which is hardly being used? 
>>
>> If so, we could solve your issues and get what we need at the same time by making scrollX/Y relative to the layout viewport
>> and pageX/YOffset relative to the visual viewport.
>
>The most common problem I saw (though it's not limited to this) was positioning popup menus, e.g. when a button is clicked, by getting the button's rect via getBoundingClientRect (layout viewport relative) and then positioning a menu using position: absolute and converting to document coordinates by adding window.scrollX/Y.

Wow. Just wow. I suppose this solution was posted somewhere and copied countless times. It doesn't make any sense whatsoever - though I admit it works. But I see now what you're up against.

>
>Yes, we could solve the immediate problem by making pageX/YOffset different but I'm afraid of repeating this situation. scrollX is defined to be equivalent to pageXOffset so changing that may cause other surprises. 

I'm not saying this is the most brilliant idea ever, but I know that the visual viewport's scrolling offset has some uses - possibly more uses than the layout viewport's.

>In my experience, the model of shipping a brand new (properly named) API, giving developers an appropriate runway to make changes, and then deprecating the old feature has worked much better and I think can work well in this case. Additionally, it has the very real benefit of being able to do feature detection: |if (window.visualViewport) window.visualViewport.getBoundingRect()| ?

Totally agree. A new API is the way forward, though I will continue to fight for backward compatibility.

I use window.innerHeight for testing whether an anchor is visible in the window: something like this pseudocode:

    elem = document.getElementById(anchor);
    return window.innerHeight >= elem.getBoundingClientRect().top;

Just adding another datapoint.

Comment 65 by maxar...@gmail.com, Feb 18 2016

#64 There's a workaround for that, though. To check if an element is below the current viewport you can check if the bottom property is negative.

Comment 67 by maxar...@gmail.com, Feb 18 2016

#66 Apologies, that's indeed another field where window.innerHeight could have come in handy in a mobile environment. I haven't checked, but I suppose document.documentElement.clientHeight doesn't work?
#65 `bottom` is relative to the top of the viewport, not the bottom, so it only goes negative if the element goes off the top.

Comment 69 by juw...@gmail.com, Feb 18 2016

Since Chrome broke visual viewport, I think, it is waste of time to look for any workaround.
There is no technical way left to recognize visible viewport on Chrome after zoom-in,  do not irritate peoples please with opposite statements!
If I am wrong and there is still some hidden way, than give a real working example.

Comment 70 Deleted

Comment 71 Deleted

This has caused issues with a piece of software which I have created for a company. It is a mobile drawing/sketch app which requires menu bars along the top, bottom and right hand side to remain in view in at all times - not matter the zoom amount. I rely on window.innerWidth to scale and keep these menus in view. By looking at this I can no longer upgrade Chrome past 47.0.2526..

Why has the behavior of window.innerWidth suddenly changed ? Why does there seem to be no alternative ? 

DISAPPOOOINTED! (https://www.youtube.com/watch?v=_O1hM-k3aUY)

This behavior breaks our advertising product... where is the transition period for this change?

Internet Explorer 10 introduced similar behavior in immersive browsing mode (Windows 8) and they got rid of it with Internet Explorer 11. We've had lots of difficulties with other browsers as well, but for a few years we haven't had any problems positioning our ad elements. And now this... It feels like a set back.

Don't get me wrong, the panning principle makes sense, but I think that it would have been much better if you would have introduced new variables and event listeners before/with this change. (onWebkitPan, window.webkitPanningX/Y, window.webkitPinchZoomLevel)

This breaking change literally breaks some websites and, unfortunately it also breaks a part of our advertising technology.

I really hope that this change is rolled back quickly and re-introduced with proper handles for solutions that require to be in the viewport at all time.

Comment 74 by sim...@opera.com, Feb 22 2016

Please email www-style with [cssom-view] in the subject line if you want to propose a new API. Thx!

Comment 75 by bokan@chromium.org, Feb 22 2016

Hi folks,

Just to update: we've decided to put this change back behind a flag in M49 - meaning the default behavior will be that innerWidth/Height/scrollX/Y will reflect the visual viewport. This will be temporary while we work out a new API that's explicitly aimed at the visual viewport. After that ships (and a transition period), we'll re-ship this change. We still think this is the right change but underestimated the amount of dependence on this (sorry!) so giving authors an alternative should reduce the pain.

In the mean time, I'd like to encourage site authors/developers to test using the Chrome Beta channel so these kinds of issues can be brought up sooner in the development cycle and before they ship.

Comment 76 by bokan@chromium.org, Feb 22 2016

Re #64,

element.getBoundingClientRect returns a rect relative to the layout viewport, meaning that the values don't change when you pinch-zoom in and the given snippet (and followup suggestions) all won't do what you expect. This kind of confusing/mixed API is what we're trying to clean up.

Comment 77 by juw...@gmail.com, Feb 22 2016

>>This will be temporary while we work out a new API that's explicitly aimed at the visual viewport. After that ships (and a transition period), we'll re-ship this change
That does not sound perfect at all.
Isn't it  better to agree with all browser developers (from FireFox mobile, IE mobile, Safari iOS) to reflect visible viewport for innerWidth/Height/scrollX/Y, but create new API for layout viewport instead.
Because I have my big doubts, that other mentioned browser developers will follow your change/API requirements, and we the community, have finally a mix of different viewports values to support visible viewport.
I mean, smarter in my humble opinion would be to quiet agree under browsers that innerWidth/Height/scrollX/Y will reflect always visible viewport, but for layout viewport create new API instead.
Change it now back, than change somewhen again, that sounds not smart.
Change back, but create new API for layout viewport would sound smart.
Of course in my opinion.
I just hate it, if we have to sniff for browser versions, and be always attentive, that Chrome will break it again, but just watch out when. 
Peoples that's just crazy!
Thank you for letting us know and thank you for listening to us. Can you recommend a way for us to stay up-to-date on this particular matter?

Comment 79 by bokan@chromium.org, Feb 22 2016

Re: Why not make a new API for the layout viewport instead?

innerWidth/Height and scrollX/Y are the exception. Most APIs are relative to the layout viewport (e.g. getBoundingClientRect, elementFromPoint, Event coordinates, etc.).

Comment 80 by bokan@chromium.org, Feb 22 2016

Re #79, for now, this bug is the best way. I'll redirect discussion/attention to new bugs as they come.

Comment 81 by juw...@gmail.com, Feb 22 2016

>>Most APIs are relative to the layout viewport (e.g. getBoundingClientRect, elementFromPoint, Event coordinates, etc.).
But that is anyway intuitive, that these functions depend on layout viewport.
And we speak explicitely about innerWidth/Height and scrollX/Y 
In my opinion, they should stay in their nature relative to visible viewport.
Just explain me, where is any good example to make these values to be relative to layout viewport after zoom-in?
I mean, it is pretty intuitive that anyone expects by zoom-in changed scroll position of entire document/window.
And by innerWidth/Height, what does it reflect now after Chrome broke visual viewport? In my opinion it does not reflect anything.. just two variables innerWidth/innerHeight that are now there just for fun.

Project Member

Comment 82 by bugdroid1@chromium.org, Feb 22 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/835268c26a1f84e944b70d69703a54c4cb50bc5b

commit 835268c26a1f84e944b70d69703a54c4cb50bc5b
Author: ymalik <ymalik@chromium.org>
Date: Mon Feb 22 16:28:12 2016

Reverting changes that made window.scroll properties relative to the layout viewport.

Reason for revert:
Broke a bunch of sites that relied on visual viewport coordinates
(see www. crbug.com/571297 ). Reverting temporary until a new api that provides visual
viewport coordinates is made available to developers.

Revert "Make window.scroll properties relative to the layout viewport by default."

This reverts commit f75faf53de4a5c59269143b6edbfc6dc40c7fb33.

Revert "Remove plumbing for the inert-visual-viewport flag."

This reverts commit 58d42ae1d6690a9f625e23f160b346e9cebeab01.

TBR=avi@chromium.org,kenrb@chromium.org
BUG= 571297 

Review URL: https://codereview.chromium.org/1712743002

Cr-Commit-Position: refs/heads/master@{#376742}

[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/chrome/app/generated_resources.grd
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/chrome/browser/about_flags.cc
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/public/common/common_param_traits_macros.h
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/public/common/content_switches.cc
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/public/common/content_switches.h
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/public/common/web_preferences.cc
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/public/common/web_preferences.h
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/content/renderer/render_view_impl.cc
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/LayoutTests/fast/dom/Window/window-scaled-viewport-properties-expected.txt
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/LayoutTests/fast/dom/Window/window-scaled-viewport-properties.html
[add] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/LayoutTests/fast/dom/window-inner-size-scaling-expected.txt
[add] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/LayoutTests/fast/dom/window-inner-size-scaling.html
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/LayoutTests/fast/repaint/fixed-right-bottom-in-page-scale.html
[delete] https://crrev.com/c7580b234892699d3b76b44702e5b3572af663aa/third_party/WebKit/LayoutTests/fast/scroll-behavior/visual-viewport-scroll-no-onscroll-event-expected.txt
[delete] https://crrev.com/c7580b234892699d3b76b44702e5b3572af663aa/third_party/WebKit/LayoutTests/fast/scroll-behavior/visual-viewport-scroll-no-onscroll-event.html
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/Source/core/frame/Settings.in
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/Source/core/testing/DummyPageHolder.cpp
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/Source/web/WebSettingsImpl.cpp
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/Source/web/WebSettingsImpl.h
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/Source/web/tests/VisualViewportTest.cpp
[modify] https://crrev.com/835268c26a1f84e944b70d69703a54c4cb50bc5b/third_party/WebKit/public/web/WebSettings.h

Comment 83 by bokan@chromium.org, Feb 22 2016

Re #81,

For an example, just look up comment #64. Mixing both concepts in one API leads to mistakes.

Your assumption is that everyone using innerWidth/height is using it for pinch-zoom which is not the case. Making it relative to the layout viewport means that in the 90%+ of cases where authors are not coding something to react to pinch-zoom, their code will function intuitively when the user zooms in.

Having an explicit API means that pinch-zoom (and soon other UI like OSK) will only affect code that was intentionally written to react to it and not cause accidental UI damage and frustration for users when authors weren't thinking about pinch-zoom.

Comment 84 by juw...@gmail.com, Feb 22 2016

>> 90%+ of cases where authors are not coding something to react to pinch-zoom,
Where did you get that number of 90%. Any good source where I could check it to agree with you, or you told it just for fun because it is your feeling that could be so? Because I could say with same success that 99% of developers expect behind innerWidth/Height visual viewport.
The good question, why do you believe, innerWidth/Height should reflect layout viewport and not visible viewport?
It is very good question in fact, because if you as developer are going to ask google, how to position/resize elements after zoom-in, you will find thousands of different topics, that describe to use innerWidth/Height with scrolling positions.
I just I have no idea, who do you mean with these 90% who assumes that innerWidth/Height should reflect some ephemeral values..

Comment 85 by mihai...@gmail.com, Feb 22 2016

This is great news, and it boosts the credibility of Chrome/Chromium team!

The downside is that v48 will remain broken, and there are cases where it matters. If you follow QuirksMode/PK research, you already know that.

Please please consider this case as a learning and take it on board. It may really harm Chrome's record if intentional compatibility breakages like that are allowed to continue.

Thanks again for listening @bokan

Comment 86 by juw...@gmail.com, Feb 22 2016

By the way what about position: device-fixed, as replacement to new behaviour of position: fixed bound to layout viewport instead visible viewport like in older Chrome.
I do not expect that new behaviour will be reverted, but would be nice to support at least device-fixed instead.

Comment 87 by bokan@chromium.org, Feb 22 2016

>> Where did you get that number of 90%. Any good source where I could check it to agree with you, or you
>> told it just for fun because it is your feeling that could be so?

Sorry - yes, "90%" should really be an unqualified "most" and it's anecdotal but you'd be hard pressed to convince me otherwise since I have yet to see *any* page in my day-to-day browsing react to pinch-zoom, where "react" means the content purposefully changes by somehow listening to changes in innerWidth/Height. Not that they don't exist (as this bug shows), but it's not a mainstream use case.

>> The good question, why do you believe, innerWidth/Height should reflect layout viewport and not visible viewport?

Please see the answers in the thread, I've already addressed this thoroughly.

>> Because I could say with same success that 99% of developers expect behind innerWidth/Height visual viewport.

The number of bugs duplicated into  issue 489206  would say otherwise. (Or that most developers are even aware of or care about the layout/visual distinction).

>> By the way what about position: device-fixed, as replacement to new behaviour of position: fixed bound to
>> layout viewport instead visible viewport like in older Chrome.

We are indeed working on device-fixed, see issue 542770

Comment 88 by juw...@gmail.com, Feb 22 2016

>> Not that they don't exist (as this bug shows), but it's not a mainstream use case.
That is your personal opinion, not the opinion of internet community.
If you ask why?
Here comes the answer. We developers, do not develope for one specific browser, we do that for all existing browsers at once.
And in the thread that you provided, nobody refers to other browsers than Chome.
Why you do not ask back, is that behaviour, that was experienced on Chrome experienced same way on FireFox mobile, on iOS Safari and on MobileIE?.
These refer to visual viewport by these variables(innerWidth/Height/pageXYOffset), and not to layout.

And now some one comes with idea how it should be on Chrome, and you are going to play pioneer for him to break common behaviours presented on mainstream browsers.

The thread your provided just shows one more time, this guy wanted specific behaviour that was not present on mainstream browsers, so why you did not create for such peoples extra API.
I think, you should really care about compatibility, and stop breaking that worked fine before. Extending browser with new features, yes, I agree, breaking actual features, NO never do that please!

Comment 89 by juw...@gmail.com, Feb 23 2016

By the way, just for info.
According to MSDN
https://msdn.microsoft.com/en-en/library/ms531140%28v=vs.85%29.aspx
IE browser supports position: -ms-device-fixed.
When Chrome changed position: fixed from visible to layout viewport, you broke one point but did not create second.
Are now Microsoft developers smarter than from Google? Good question, why you do check compatibility before releasing broken things? I still do not understand, what is wrong with you guys?
Good you are listening to us and learning to get better.
And since IE browser does not support minimum zoom via meta tag or min-zoom in @-ms-viewport rules I simulate it by setting
document.body.parentNode.msContentZoomFactor which seems to change always when entire document is zoomed.
At least that could be replacement for innerWidth/Height..
However, I never understand the points, when there are redundant variables.
like window.scrollX == window.pageXOffset and window.scrollY == window.pageYOffset
May be window.scrollXY sound more on layout viewport and window.pageXYOffset on visible viewport, and possibly that is good time, when these different variables go apart.
So you would catch two flies at once and make all happy.
Just one of possible ways to go when you are going to break something again :)

Comment 90 by juw...@gmail.com, Feb 23 2016

Next interesting point I found just by googling
(even if it has nothing to do with Chrome, but FF-mobile, but at least you will see, you are not first person as developer facing the problem of which way to go)
https://bugzilla.mozilla.org/show_bug.cgi?id=1123938#c6

"Late in our shipping process we found this broke a number of websites, and was also inconsistent with IE's behavior.  So we switched scrollX/Y, scrollTo/scrollBy and innerWidth/innerHeight to take the visual viewport into account."
Now you see, the hope, that other browsers will follow your path is busted ;-) as I told, I had my doubts that other browsers would make something similar like you, and I was right.. and I think, they won't go back to this question again.
So please review properly your future intentions to change the behaviours.

Cc: -klo...@chromium.org kerzklobag@chromium.org kerz@chromium.org
Labels: Merge-Request-49

Comment 92 by shey...@google.com, Feb 23 2016

Labels: -Merge-Request-49 Merge-Review-49 Hotlist-Merge-Review
[Automated comment] GRD changes detected, less than 3 weeks to before stable release of M49, manual review required.

Comment 93 by k...@google.com, Feb 23 2016

Labels: -Merge-Review-49 Merge-Approved-49
Strings are in flags, so nor a big deal.
Please merge your change to M49 (branch: 2623) before 5:00 PM PST Today [02/23] if you would like to make it to Desktop M49 Beta push on Wednesday [02/24].
Project Member

Comment 95 by bugdroid1@chromium.org, Feb 23 2016

Labels: -merge-approved-49 merge-merged-2623
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6fa68739e94ac02e8b2363b36eca05b9591ded0f

commit 6fa68739e94ac02e8b2363b36eca05b9591ded0f
Author: Yash Malik <ymalik@google.com>
Date: Tue Feb 23 20:06:23 2016

Reverting changes that made window.scroll properties relative to the layout viewport.

Reason for revert:
Broke a bunch of sites that relied on visual viewport coordinates
(see www. crbug.com/571297 ). Reverting temporary until a new api that provides visual
viewport coordinates is made available to developers.

Revert "Make window.scroll properties relative to the layout viewport by default."

This reverts commit f75faf53de4a5c59269143b6edbfc6dc40c7fb33.

Revert "Remove plumbing for the inert-visual-viewport flag."

This reverts commit 58d42ae1d6690a9f625e23f160b346e9cebeab01.

TBR=avi@chromium.org,kenrb@chromium.org
BUG= 571297 

Review URL: https://codereview.chromium.org/1712743002

Cr-Commit-Position: refs/heads/master@{#376742}
(cherry picked from commit 835268c26a1f84e944b70d69703a54c4cb50bc5b)

Review URL: https://codereview.chromium.org/1724103002 .

Cr-Commit-Position: refs/branch-heads/2623@{#475}
Cr-Branched-From: 92d77538a86529ca35f9220bd3cd512cbea1f086-refs/heads/master@{#369907}

[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/chrome/app/generated_resources.grd
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/chrome/browser/about_flags.cc
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/public/common/common_param_traits_macros.h
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/public/common/content_switches.cc
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/public/common/content_switches.h
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/public/common/web_preferences.cc
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/public/common/web_preferences.h
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/content/renderer/render_view_impl.cc
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/LayoutTests/fast/dom/Window/window-scaled-viewport-properties-expected.txt
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/LayoutTests/fast/dom/Window/window-scaled-viewport-properties.html
[add] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/LayoutTests/fast/dom/window-inner-size-scaling-expected.txt
[add] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/LayoutTests/fast/dom/window-inner-size-scaling.html
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/LayoutTests/fast/repaint/fixed-right-bottom-in-page-scale.html
[delete] https://crrev.com/06895c9421d30cb5da037b861c9d0a7b87771220/third_party/WebKit/LayoutTests/fast/scroll-behavior/visual-viewport-scroll-no-onscroll-event-expected.txt
[delete] https://crrev.com/06895c9421d30cb5da037b861c9d0a7b87771220/third_party/WebKit/LayoutTests/fast/scroll-behavior/visual-viewport-scroll-no-onscroll-event.html
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/Source/core/frame/Settings.in
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/Source/core/testing/DummyPageHolder.cpp
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/Source/web/WebSettingsImpl.cpp
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/Source/web/WebSettingsImpl.h
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/Source/web/tests/VisualViewportTest.cpp
[modify] https://crrev.com/6fa68739e94ac02e8b2363b36eca05b9591ded0f/third_party/WebKit/public/web/WebSettings.h

Cc: ranjitkan@chromium.org
Labels: TE-Verified-M49 TE-Verified-49.0.2623.63
Rechecked this on chrome version 49.0.2623.63 on Windows 7, MAC 10.11.3. Fix / revert is working as intended. Pinch-zoom state is exposed to JavaScript, and  changes values when performed Zoom in and Zoom out operations.

Adding TE- Verified Labels.

Comment 97 by juw...@gmail.com, Feb 24 2016

What is about Chrome Android mobile, when it is ready to check?

Comment 98 by bokan@chromium.org, Feb 24 2016

It should hit the next M49 beta - probably in the next day or two
Is there a proper way to check this innerWidth support on the client-side via js so that we can whitelist some features based on it?
No, we've reverted the current change so there's no difference to check right now. When we do reintroduce it with a replacement API it'll likely be a feature check on the new API (e.g. if(window.visualViewport)) but that's still not fully baked yet. We'll publish recommended usage when that doe ship.
Project Member

Comment 101 by bugdroid1@chromium.org, Feb 25 2016

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/6fa68739e94ac02e8b2363b36eca05b9591ded0f

commit 6fa68739e94ac02e8b2363b36eca05b9591ded0f
Author: Yash Malik <ymalik@google.com>
Date: Tue Feb 23 20:06:23 2016

In #4 and #8 you asked for pages that are pinch zoom aware e.g. by using window.innerWidth.

I think HTML canvas, especially WebGL has a need to know about pinch zoom. Since WebGL and HTML Canvas in general are pixel based it is required to increase the canvas resolution when zooming-in, to avoid a blurry display, see the recommendation from Khronos, "https://www.khronos.org/webgl/wiki/HandlingHighDPI". This recommendation is, however, based on window.devicePixelRatio and consequently only covers browser-zoom but not pinch-zoom. Consequently a WebGL canvas implemented like this looks blurryunder pinch zoom.

What I consider as a bigger problem is pinch-zooming out (as it is the default when viewing a desktop page on a phone). When zooming out the browser makes the page to be displayed believe that it is to be displayed on a desktop-wide screen. Therefore also a full window canvas on that page becomes large, often too large for handling by a small GPU of a handheld device.

For example a pinch-zoomed out page on a phone might roughly have a window.innerWidth and consequently body.clientWidth of about 1000px and a window.devicePixelRatio=3 leading to a 3000px wide canvas (following the recommendation). This is too hard for many (mobile) GPUs.It would however be possible to do the WebGL calculations at a much lower resolution (e.g. 1000px wide for a zoom factor of 1/3), without losing much quality since the final picture is shrinked by the zoom before final display.   

My site http://www.taccgl.org/index.html currently does not take pinch-zoom into account. It is a desktop page and has a redirection to a mobile site for phones. This desktop page follows the Khronos recommendation and magnifies the canvas by the window.devicePixelRatio and therefore fails, degrades, or deactivates WebGL on most mobile devices, when shown in the default pinch-zoomed-out state of a desktop page.

I have an experimental (not yet online) version dividing window.devicePixelRatio by some rounding of 
window.innerWidth / window.outerWidth which reduces the canvas size on zoom out and increases it on zoom-in. I guess however, that window.innerWidth / window.outerWidth is just an approximation, since
the window.outerWidth sometimes includes space needed for a window border etc.If the factor is not totally correct this could mean that the bitmap of the canvas is resized before display on the physical screen with the well known quality problems of resizing. Also this formula
only works for pinch-zoom and not for browser-zoom and so requires some detection first.


Re#102: thanks, that's a good example of cases we want to capture.

For the zoom in case, would adjusting the dimensions by the page scale be a good idea? If you zoom in to 500%, on a device with a DPR of 3 you'll have a deviceSize*15 sized canvas, quite huge. Or is the idea that you can clip the surface to just what's visible?

For the zoom out case, it sounds like what you really want in that case is to be using a viewport meta with device-width: <meta name="viewport" content="width=device-width"> so that the page's layout width matches the screen width of the device.

AFAIK, window.innerWidth/window.outerWidth should work for page scale today on mobile browsers, I believe that none of the mobile browsers have a border around the sides (I know Chrome doesn't), although on desktop it'll break.
>> For the zoom in case, would adjusting the dimensions by the page scale be a good idea? 
>> If you zoom in to 500%, on a device with a DPR of 3 you'll have a deviceSize*15 sized
>> canvas, quite huge. Or is the idea that you can clip the surface to just what's visible?
Yes, it is the idea to clip the canvas to its visible part. Unsually we conceptually have a canvas covering a complete document,however implemented is a canvas that is absolutely positioned and sized (using body.scrollTop, body.scrollLeft, window.pageXOffset, window.pageYOffset, ***window.innerWidth*** and window.innerHeight) to cover only the visible part of the document. WebGL is told to render the corresponding part of the scene only. On zoom-in the logical size of the canvas shrinks, which compensates for  the increase in resolution so that effectively the number of physical pixels of the canvas stays roughly constant. (There are still many other problems with 500% zoom e.g. texture sizes in WebGL and a dpr of 3 requires a real small deviceSize and fast GPU, but this is probably not relevant here). In fact the clipping of the canvas is also required to minimize the size of the canvas in case of scrolling documents. Even then some devices are just too slow for a full window webgl canvas.



>> For the zoom out case, it sounds like what you really want in that case is to be using 
>> a viewport meta with device-width: <meta name="viewport" content="width=device-width"> 
>> so that the page's layout width matches the screen width of the device.
Although I agree that this is the best, I am building a WebGL javascript library for use in whatever pages and so the <meta...> is out of my control. 

The solution described, however, now works fine in the zoom-out case as well, although the zoom-out makes the logical HTML size of the canvas grow large, the resolution of the canvas can be reduced according to the zoom factor and so the number of physical pixels stays roughly constant.

The problem I have are devices where it is not clear if pinch- or browser-zoom (or both?) is applied, such as laptops or desktops with touch; simply because I have two solutions, one for each kind of zoom, but still need to know which to apply. There I hope for the new API you seem to be working on (according to #38).

Status: Fixed (was: Assigned)
Hi folks,

Just to update, Chrome just landed an experimental implementation of a new viewport API described in https://github.com/WICG/ViewportAPI. It's available now in Chrome Canary on Windows/Mac and should hit Android dev-channel in the next few days. You can turn it on using the "enable-experimental-web-platform-features" flag in chrome://flags. The proposal itself is initial and I expect the details to change as we debate the finer points but please give it a try, feedback would be appreciated! Thanks.

Oh, and you can follow  issue 595826  for further updates on this API. I'm going to mark this bug as fixed since the change this bug tracks have been reverted.
I am literally leaving Google chrome is if this doesn't go back to the way it was. Zoom is totally messed up.
This was reverted to the previous behavior. If you're still seeing issues please file a new bug.

Comment 108 by juw...@gmail.com, Apr 6 2016

Hello,

what I do not entirely understand, why you (developers behind Chrome) insist on implementation of visual viewport api instead layout viewport api?
Any good reason for doing that this way?
Let's assume following scenarios.
A developer XYZ wants to reuse layout viewport, he uses window.innerWidth/innerHeight etc. representing layout viewport according to new API (as opposite api to visual viewport)
Now he is fine with Chrome, possibly happy, that the site is working as expected on Chrome browser with window.innerWidth/innerHeight etc.
Now this XYZ developer opens his programmed code on Android FireFox, iOS Safari and IE10/11 Mobile and what does he see after pinch-zoom?
The site is totally broken and does not behave as he would expect like it does on Chrome with layout viewport.

Now we on another side, developers ABC, that expected visual viewport behind window.innerWidth/innerHeight will get expected behaviour on Android FireFox, iOS Safari and IE10/11 Mobile, but have different behaviour on Chrome Android where we now have to switch extra to new api to get same behaviour.

The question, what did here went the wrong way?

Isn't it smarter to create for developer XYZ layout viewport API, inform him about, that he now has to use xyz.innerWidth/innerHeight etc. for layout viewport and leave visual viewport like it was before for full backward compatibility?

I just do not understand the logic behind this jeopardizing of different variables and their meaning under different browsers.
As I have mentioned before, I have my big doubts that iOS Safari/IE Mobile/FireFox Android will change the old behaviour to support visual viewport as extra api, more over they explicitely claimed (FireFox), they won't do that.

So in end effect we developers ABC are idiot because we need to create different polyfills for backward compatibility and developers XYZ will be idiot, because their code will work only on Chrome as they expect it to behave after pinch-zoom.

But if developer XYZ would have layout viewport API instead viewport API, he would at least know, aha, to make it working on Chrome as expected he just needs to use layout viewport api until iOS Safari/IE Mobile/FireFox Android support it some when like Chrome, and we developers XYZ would not need to change anything to make site working on all different browsers.

It is just my opinion, in case of Viewport Api all developers, XYZ and ABC, are loosers and need to invent new wheels.
Hi everyone. If you're interested in developing against the visual viewport, Chrome Canary should now have an initial implementation of the visual viewport API behind a runtime flag. You can see the details and some examples here: https://github.com/WICG/ViewportAPI. The visual viewport API can be turned on with chrome://flags/#enable-experimental-web-platform-features. Please try it out and feel free to file GitHub issues with feedback/suggestions/criticisms/etc.

Thanks!

Comment 110 Deleted

For anyone still keeping tabs here, I've relanded the fix to  issue 489206  which will once again hide pinch-zoom state from the page (in window.innerWidth/Height,scrollX/Y). This will ship to stable in M61 (sometime in September).

However, this time we'll ship it alongside a new Viewport API (https://github.com/WICG/ViewportAPI). This should allow you to do everything you could before along with some new goodies (event for zoom, explicit `scale` attribute, and more). This is currently enabled in Chromium ToT (to hit stable in M61) and should be hitting Canary/Dev channels shortly.

If you're relying on the `window` attributes reflecting pinch-zoom you should feature detect for `window.visualViewport` and use that instead. Better yet, use (and contribute) to the polyfill in the github repo above.
Blockedon: 489206

Comment 113 by y...@zendesk.com, Jul 17 2017

Is it intended that the inert viewport is turned off by default in Canary v61? I thought it was supposed to be shipped simultaneously with the visualViewport API and that detecting visualViewport should be sufficient for ascertaining the inert viewport.
That's not intentional, it should be turned on. I'm currently looking into  issue 740956 , feel free to file a bug if you're also not seeing it in a situation that's different from that bug.
Re#113, sorry, due to a bug this didn't actually get enabled on any platform (thanks for bringing it to my attention) - I should have a fix for that today.
Showing comments 16 - 115 of 115 Older

Sign in to add a comment