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

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 767388: window.innerWidth/Height should give the visual viewports dimensions

Reported by, Sep 21 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

Steps to reproduce the problem:
1. Go to in Chrome 61+/Android and in another non-Chrome browser of your choice.
2. Note the window.innerWidth/Height values.
3. Zoom in in the other browser, and press "Refresh tests". window.innerWidth/Height now gives the current size of the visual viewport.
4. Repeat the experiment in Chrome 61+/Android. window.innerWidth/Height does not change.

What is the expected behavior?
window.innerWidth/Height should expose the dimensions of the visual viewport.

What went wrong?
This is a deliberate change in Chrome 61 that I strongly object to, since it breaks compatibility with ALL other mobile browsers.

See for my full argument.

Did this work before? Yes 60

Does this work in other browsers? Yes

Chrome version: 61.0.3163.91  Channel: stable
OS Version: OS X 10.12.6
Flash Version:

Comment 1 by, Sep 21 2017

See also  bug 571297 , which is an exact duplicate of this one, but then in Chrome 48. The arguments proposed here continue to hold merit.

Comment 2 by, Sep 21 2017

FWIW on Linux Chromium Version 61.0.3163.91 (Developer Build) (64-bit) I cannot reproduce the issue (counter checked numbers VS Firefox too, innerWidth seems to be consistent)

Comment 3 by, Sep 21 2017

Components: Blink>Layout
Labels: -OS-Mac OS-Android

Comment 4 by, Sep 21 2017

Labels: Needs-Bisect Needs-Triage-M61

Comment 5 by, Sep 21 2017

Labels: Needs-triage-Mobile

Comment 6 by, Sep 22 2017

Status: Assigned (was: Unconfirmed)
aelias: Is this related to the work to use page zoom for device scale?

Comment 7 by, Sep 22 2017

Labels: -Needs-Bisect hasbisect-per-revision M-63 Triaged-Mobile
Able to reproduce the issue in Android. Observed the window.innerWidth/Height values are not changing on zooming in.

Steps Followed
1. Launched Browser
2. navigated to 
3. Zoomed in and refreshed the page
3. Observed the window.innerWidth/Height values are not changing on zooming in.

Chrome versions tested

Android 8.0.0, 6.0.1, 

Android Devices
8.0.0 Nexus 6P Build/OPR1.170623.011, 6.0.1: SM-J710F Build/MMB29K

Chrome Good Build -- 61.0.3160.0
Chrome Bad Build  -- 61.0.3162.0

Results from pre revision bisect --
You are looking for a change made after 488017(GOOD), but before 488018(BAD).

From the above revision range suspecting the following --

@bokan -- Could you please look into the issue, kindly re-assign if this is not related to your changes.

Issue is seen in M63 as well.

Thank You.

Comment 8 by, Sep 25 2017

Components: -Blink>Layout Blink>Scroll
Labels: Hotlist-Input-Dev
As noted in the original message, this was an intentional change - "inert visual viewport". Intent to ship here:!msg/blink-dev/kbcFPnvDwUc/P2PLzcGhBAAJ

The main difference from  issue 571297  is that the new `window.visualViewport` API replaces the lost functionality this change brings. Motivated developers can now work around this change (and in a better way).

The reason we made this change is it _fixes_ many existing compat issues:  issue 489206  has dozens of bugs dup'd into it. Anecdotally, it has made the browsing experience on zoomable desktop platforms (e.g. Mac) better - it fixes zoom bugs on major pages like Instagram and YouTube. Developers were struggling with the existing behavior, see comments #52/#53 in  issue 489206 .

This change was made in consultation with other browser vendors. Safari is working on converting to this behavior as well. Edge has agreed in principle but is waiting to see what our experience with compatibility with existing pages is like. (Firefox doesn't use the two viewport model yet). So while we are moving first here, the goal is that eventually all browsers will behave this way.

I do worry about compatibility impact and that could cause us to change course here. So if you have examples of sites that break please report them. In particular, large popular sites would carry a lot of weight. However, I haven't seen any examples like that yet. Given how hard it is to build reliable pinch-zoom experiences that work across browsers I'd be surprised to see many. Another consideration is how the page's behavior changes. This change makes it so pages don't react to zoom so I expect most differences in behavior wouldn't be percieved by users as "broken". I'm most concerned about pages breaking in a way that impacts usability or experience.

Comment 9 by, Sep 28 2017

Wasn't the whole point of wrapping this functionality in the new VisualViewport API to minimize the impact to existing applications? So why weren't there, at the very least, any release notes indicating the changes that were made to the meaning of established properties (innerHeight, innerWidth, etc.)?

We utilize a 3rd-party library for modal dialog windows, that has been in place for many years, in several large intranet ERP systems for our customers. This library uses those long-established properties to determine how to center a modal dialog on the screen at the current scrolling position. As of this week, Chrome users could no longer see those modal dialogs because they were popping up outside the bounds of the screen.

The idea that "motivated developers can now work around this change" is true. But to imply that years worth of stable cross-browser development work should be broken without warning, because there is a new way of doing things that other browsers MIGHT adopt, is frustrating.

My request would be to revert the meaning of these properties and to expose the desired values through separate API features. Then educate the development community on the new recommended approach and its advantages, while existing code continues to operate smoothly. Otherwise, as I witnessed this week, the response from the end-user community becomes, "Things don't work correctly in Chrome. Just use Firefox."

Comment 10 by, Sep 28 2017


I publicised the change in the previous  bug 571297  which had a lot of exposure when this was shipped in M40. It was also mentioned in the article on the visualViewport ( It should have been in the release notes but taking a look now it seems it isn't, that's a mistake - sorry!

Could you provide me with a demo page or a minimized repro of the broken modal dialogs - I'd like to understand this case better? (also, what's the 3rd party library you mentioned?) In general, this should still work until the user zooms in. The one way I just realized this might break is if the page is initially zoomed (e.g. initial-scale=1 in viewport meta)...if the user zooms all the way out the dialog would be in the center of the screen. If that's the case, the easiest fix would be to set the minimum-scale to the initial-scale as well.

Comment 11 by, Oct 6 2017

please fix chrome fast tnx

Comment 12 by, Oct 9 2017

Happy to see the action taken. Kudos.

Comment 13 Deleted

Comment 14 by, Oct 18 2017

Re #9 -- exactly the situation for our application, which uses a 3rd party library.  We are small fish (only 225 companies use our app).  We recommend I-Explorer to our customers but many of them prefer to use Chrome.  (As do I.)  We'll again recommend they move to I.Explorer but I wish we didn't need to.

Comment 15 by, Oct 18 2017

Re #14, I have some questions which I didn't get an answer to from #9. Since you're recommending IE, I'm assuing your app is primarily used from desktops? If that's the case, this change shouldn't have a (significant) effect - maybe it's a different issue? Could you also point me to the 3rd party library?


Comment 16 by, Oct 19 2017

Our problem sounds like that described in Comment 9, although it was modal windows and we are using positioned "context menus".  We used DevExpress (11.1) for menus and pulldowns in our VB .Net application.  The application was developed a few years ago and we don't have access to updates to DevExpress (without significant expense).  A complete replacement is in development so we don't look to invest more cost into the existing application.

The primary problem is menu box misplacement for submenus (cascading menu).  The context menu might be anchored on the "wrong end" vertically, but it's visible.  The problem is with the DevExpress library placement of any submenu.  These are misplaced so they are invisible, the problem is observed in normal use with an initial zoom of 100%. Customers will report they are invisible, but after much inspection, we finally realized they were misplaced, and could be "found" by scrolling or by reducing zoom.

If the menu appears within an element such as a datagrid, the problem either doesn't occur or is contained within the visible page so the customer can find the menu.  (In your words, it's not a significant effect.)  But with a scrollable page there's no workaround that a typical application user would understand (nor accept).

I'll attempt to attach a picture zoomed out to show the submenu position.  At normal 100% zoom where the context menu was visible, the submenu would likely be in this scrolled past portion of the page, thus invisible.
98.0 KB View Download

Comment 17 by, Oct 19 2017

Thanks for the explanation. I'm suspecting your issue is unrelated to the change pointed out by this bug. To clarify, when you talk about zoom, do you mean "browser zoom" (i.e. ctrl +/-) or "pinch-zoom" (using a touchscreen)?

This bug is specifically about a change to pinch-zoom only (and it was made to fix these kinds of bugs), if it's browser zoom then it's unrelated (but we may still want to take a look). You mentioned IE, does the issue reproduce in any other browsers? Do you have a test page I could have a look at to determine what the differences might be between browsers?

Comment 19 by, Oct 19 2017

Ah, yes - that's related to a different change ( issue 157855 )

Comment 20 by, Oct 20 2017

alright... that issue looks years old and we've only encountered this problem this month but.... regardless the devexpress solution looks to work for us regarding this recent change.

Comment 21 by, Oct 20 2017

The issue is years old but the change/fix to align with other browsers happened only recently in M61.

Comment 22 by, May 15 2018

 Issue 842863  has been merged into this issue.

Sign in to add a comment