|window.innerWidth/Height should give the visual viewports dimensions|
|Reported by pp.k...@gmail.com, Sep 21||Back to list|
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 https://quirksmode.org/m/tests/widthtest.html 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 https://www.quirksmode.org/blog/archives/2017/09/chrome_breaks_v.html 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:
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.
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)
aelias: Is this related to the work to use page zoom for device scale?
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 https://quirksmode.org/m/tests/widthtest.html 3. Zoomed in and refreshed the page 3. Observed the window.innerWidth/Height values are not changing on zooming in. Chrome versions tested 61.0.3163.91 63.0.3220.0 OS 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 https://chromium.googlesource.com/chromium/src/+log/61.0.3160.0..61.0.3162.0?pretty=fuller&n=10000 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 -- https://chromium.googlesource.com/chromium/src/+/6933fe8a1b1d14e0d36a69cb27ef026217595d95 @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.
As noted in the original message, this was an intentional change - "inert visual viewport". Intent to ship here: https://groups.google.com/a/chromium.org/forum/#!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.
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."
Re#9: 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 (https://developers.google.com/web/updates/2017/09/visual-viewport-api). 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.
please fix chrome fast tnx
Happy to see the action taken. Kudos.
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.
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? Thanks.
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.
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?
I hired someone to investigate, he discovered this report. https://www.devexpress.com/Support/Center/Question/Details/T555320/a-popup-is-not-shown-or-is-shown-at-an-incorrect-position-in-chrome-61
Ah, yes - that's related to a different change ( issue 157855 )
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.
The issue is years old but the change/fix to align with other browsers happened only recently in M61.
|► Sign in to add a comment|