170595 2017-04-07 03:54:03 -0700 window.innerWidth/innerHeight are bogus after resize/orientationchange in WKWebView (but not MobileSafari) 2025-03-21 22:58:10 -0700 1 1 1 Unclassified WebKit Layout and Rendering Other iPhone / iPad iOS 10 NEW https://bugs.webkit.org/show_bug.cgi?id=171140 InRadar P2 Major --- 1 ae webkit-unassigned ali.ghassemi bfulgham bugs cathyxz craig dennis.subachev1 diiiimaaaa ilari ilya.gorodnyanskiy matt.henry1 maximambrosevich moplam moplam samsmithsr0102 sean simon.fraser sriramkrish85 thorton tom.hamming toutoune_sk8 webkit-bug-importer wenson_hsieh yuxichen zalan ztforster oldest_to_newest 1295262 0 ae 2017-04-07 03:54:03 -0700 When my iPhone SE is rotated from portrait to landscape or vice versa, both resize and orientationchange events are generated on window (OK). However, in the respective event handlers, window.innerWidth/innerHeight have useless / bogus values. For example, in a resize handler, they'll BOTH (!) be 320 (last time I checked, my iPhone wasn't square), and in the orientationchange handler, it will still have the values from the PREVIOUS orientation. This is a major showstopper for hybrid apps that aim to support both orientations. Introduced in iOS 10.3.1. 10.2 was fine. 1295263 1 ae 2017-04-07 03:55:04 -0700 (this occurs in WKWebView) 1295345 2 webkit-bug-importer 2017-04-07 08:46:12 -0700 <rdar://problem/31501450> 1296487 3 ali.ghassemi 2017-04-11 11:08:04 -0700 This also broke AMP's image viewer in 10.3: https://github.com/ampproject/amphtml/issues/8479 Prioritized commitment to fix this would be very much appreciated. 1296493 4 sriramkrish85 2017-04-11 11:13:03 -0700 This affects a large subset of AMP pages (likely a few 100 million). This will represent a significant regression in UX. 1296496 5 ae 2017-04-11 11:22:32 -0700 If anyone is interested and/or trying to find a workaround for their situation: Both events are completely useless right now, as they never get called with the correct values for innerWidth/Height in place. The quick fix I immediately deployed in my production apps was to just introduce a timeout in the orientationchange handler (0.7s), as I hoped that after 0.7 seconds, the values are finally correct (seems to be the case). The "real" fix was to constantly check both innerWidth and innerHeight (say, 10 times per second) and if any of them changes, generate a "fake" resize event. That works, but is of course a waste of CPU and battery. 1299744 6 thorton 2017-04-21 11:56:15 -0700 Hello! Can you, by any chance, attach a test app that reproduces the regression? I can reproduce the problem, but I can *also* reliably reproduce it in earlier versions of iOS, so I'm not sure I'm testing the same thing as you. 1299749 7 307766 thorton 2017-04-21 12:00:48 -0700 Created attachment 307766 test page 1299840 8 thorton 2017-04-21 13:44:12 -0700 OK, the AMP problem is actually not a duplicate of this. Splitting that out into https://bugs.webkit.org/show_bug.cgi?id=171140. 1300196 9 ae 2017-04-22 08:27:17 -0700 (In reply to Tim Horton from comment #6) > Hello! Can you, by any chance, attach a test app that reproduces the > regression? I can reproduce the problem, but I can *also* reliably reproduce > it in earlier versions of iOS, so I'm not sure I'm testing the same thing as > you. Hello. I'm not completely sure really what changed and when, all I know is that the app's orientation change handling was broken the moment I updated to iOS 10.3.1. Here's some debug output from the handlers (window.orientation in parentheses) : --- After rotating the phone from portrait to landscape: --- ORIENTATIONCHANGE: 320 x 568 (90) RESIZE: 320 x 320 (90) App.resize (from update): 568 x 320 - wrong (old portrait) dimensions in orientationchange handler - wrong dimensions in resize handler (square!) - App.resize is the "fake" handler I wrote which manually detects size changes (fine) --- After rotating back to portrait: --- ORIENTATIONCHANGE: 568 x 320 (0) RESIZE: 320 x 320 (0) App.resize (from update): 320 x 568 - wrong (old landscape) dimensions in orientationchange handler - wrong dimensions again in resize handler Note that there's NEVER a correct 'resize' event generated with the correct values for innerWidth/innerHeight! Hope this helps. Probably a difficult one to get fixed. 1300325 10 bugs 2017-04-23 06:06:44 -0700 No idea whether this is related, but just in case… There’s also been another change in the behavior of ‘window.innerHeight’ between iOS 10.2 and 10.3.1: When you touch an input field that’s located at the bottom of a page, the virtual keyboard comes up and Safari scrolls to ensure that the field remains visible. If you have a handler attached to the window’s ‘scroll’ event and read ‘window.innerHeight’ in it, in iOS 10.2 the height was unchanged, i.e. not reduced by the height of the keyboard. In iOS 10.3.1, it *is* reduced by the height of the keyboard. 1300628 11 thorton 2017-04-24 12:59:38 -0700 (In reply to ae from comment #9) > > Hello. I'm not completely sure really what changed and when, Right, but I need to figure that out, so I can fix it! > all I know is that the app's orientation change handling was broken the moment I updated to iOS 10.3.1. > > Here's some debug output from the handlers (window.orientation in > parentheses) : Can you reduce the app to something you're willing to share? Either here, or at bugreport.apple.com if you would prefer? > Note that there's NEVER a correct 'resize' event generated with the correct > values for innerWidth/innerHeight! > > Hope this helps. Probably a difficult one to get fixed. If you can't reduce the app to something you can share, perhaps you could look at the test page that I attached and see what might be different between it and your app that causes this problem to not reproduce in the test page? I need to get to the point where I can reproduce the problem in order to diagnose. 1300633 12 thorton 2017-04-24 13:06:04 -0700 (In reply to Tim Horton from comment #11) > (In reply to ae from comment #9) > > > > Hello. I'm not completely sure really what changed and when, > > Right, but I need to figure that out, so I can fix it! > > > all I know is that the app's orientation change handling was broken the moment I updated to iOS 10.3.1. > > > > Here's some debug output from the handlers (window.orientation in > > parentheses) : > > Can you reduce the app to something you're willing to share? Either here, or > at bugreport.apple.com if you would prefer? > > > Note that there's NEVER a correct 'resize' event generated with the correct > > values for innerWidth/innerHeight! > > > > Hope this helps. Probably a difficult one to get fixed. > > If you can't reduce the app to something you can share, perhaps you could > look at the test page that I attached and see what might be different > between it and your app that causes this problem to not reproduce in the > test page? > > I need to get to the point where I can reproduce the problem in order to > diagnose. Sorry, I forgot the context. Rather, I need to figure out why your app *didn't* reproduce in older versions of iOS, when the test page does. 1306025 13 simon.fraser 2017-05-08 13:22:21 -0700 We're sending a visible rect update with unobscuredContentRect (0,0) width=320 height=320) during rotation. 1306028 14 simon.fraser 2017-05-08 13:29:18 -0700 We end up with 320x320 by virtue of: unobscuredRectInContentCoordinates = CGRectIntersection(unobscuredRectInContentCoordinates, [self _contentBoundsExtendedForRubberbandingWithScale:scaleFactor]); 1306031 15 simon.fraser 2017-05-08 13:34:45 -0700 and that's because we haven't update the contentView bounds for rotation yet (this happens on a callback from the web process), so we're intersecting 320x568 with 548x320. 1306172 16 simon.fraser 2017-05-08 17:34:22 -0700 We can fix this by avoiding the intersection with the content view bounds (which is really just there to fix rubber banding), but the layout viewport rect is still wrong because it also relies on state from the web process (the documentRect). We really need to round-trip through the web process with the new size before we can reliably compute rects. 1306313 17 ae 2017-05-09 01:33:52 -0700 Sorry I couldn't provide a real testcase yet, just completely drowned in work. But as it seems, you've already found the problem. Thanks again for looking into this. 1379837 18 ali.ghassemi 2017-12-08 15:13:43 -0800 Hi Webkit team, Given Simon has found the root cause and has a proposed fix here, is this something we can expect to see fixed soon? Current workaround with introducing 500ms+ delays really hurts users' expectations of great UX. Thank you 1380502 19 cathyxz 2017-12-11 17:54:52 -0800 Not 1380503 20 cathyxz 2017-12-11 17:58:26 -0800 Sorry, meant to find a way to subscribe / +1 to this bug, but accidentally saved a comment. 1394491 21 matt.henry1 2018-01-30 03:49:57 -0800 (In reply to Ali G from comment #18) > Hi Webkit team, > > Given Simon has found the root cause and has a proposed fix here, is this > something we can expect to see fixed soon? > > Current workaround with introducing 500ms+ delays really hurts users' > expectations of great UX. > > Thank you Ali, I'm not sure whether this will be relevant to you given that it's been a month or so since your comment, but I've had success with a zero-delay workaround by calling getBoundingClientRect() on an element that's been styled to fill 100% of the window size within the window's resize handler. 1429805 22 ilya.gorodnyanskiy 2018-06-04 07:27:22 -0700 Is this bug actually fixed in iOS 11.4? 1430074 23 maximambrosevich 2018-06-05 03:51:48 -0700 Unfortunately, yes. Test on PWA app. 1455607 24 toutoune_sk8 2018-08-31 01:01:03 -0700 I'm still have the same problem, I need to put time out to make it work. Does anyone have any other solutions ? 1489225 25 moplam 2018-12-18 22:50:43 -0800 A slightly different workaround: To avoid creating a new element, The following workaround seems to work fairly well for me: For non-Safari, get the layout viewport size from document.documentElement.clientHeight (& Width). Unfortunately, Safari's documentElement size does not update when the URL bar hides so I couldn't just apply it to all Webkit browser, but this bug just doesn't happen to Safari. 1589590 27 dennis.subachev1 2019-11-12 11:57:03 -0800 Can confirm I still see this issue. I threw the test page up on stackblitz for anyone who wants to try themselves: https://typescript-pmaukj.stackblitz.io Going portrait -> landscape -> portrait will cut off a space at the bottom of the screen the size of the menu (footer?) bar. `window.innerHeight` will _not_ include the cut off region so there is nothing that can be done to fill it until the user scrolls. This is especially a problem in our web app because we have `overflow-y: scroll` type containers that have a min and max height of `window.innerHeight`. 1659884 28 ztforster 2020-06-05 18:52:28 -0700 I am seeing the same issue in iOS 13.3.1, also in a WKWebView. I was able to work around it by implementing the solution "constantly check both innerWidth and innerHeight (say, 10 times per second)". I feel very strongly about this, as I don't rightly understand why you'd even bother implementing the resize event if window dimensions aren't going to be accurate. The way it is now, you need this hack to implement any kind of SVG visualization that needs a different aspect ratio in landscape. 1972558 29 simon.fraser 2023-08-21 20:09:39 -0700 We should probably just use ScrollView::sizeForUnobscuredContent(). Need to think about scrollbars, and content insets. 1972559 30 simon.fraser 2023-08-21 20:10:08 -0700 Currently the code uses unobscuredContentRectIncludingScrollbars() which is clearly wrong. 2105244 31 diiiimaaaa 2025-03-21 22:58:10 -0700 FYI this still happens, mostly in webviews (for example, in Chrome on iOS). The example on stackblitz above shows the issue well. Just listening for the `resize` event should be sufficient. 307766 2017-04-21 12:00:48 -0700 2017-04-21 12:00:48 -0700 test page testresize.html text/html 1290 thorton PGhlYWQ+PG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9ImluaXRpYWwtc2NhbGU9MSI+PC9o ZWFkPgo8c3R5bGU+CmRpdiB7CiAgICBib3gtc2l6aW5nOiBib3JkZXItYm94Owp9CgojbGFzdG9y aWVudGF0aW9uY2hhbmdlIHsKICAgIHBvc2l0aW9uOiBhYnNvbHV0ZTsKICAgIGJvcmRlcjogMTVw eCBzb2xpZCBncmVlbjsKCiAgICB0b3A6IDA7CiAgICBsZWZ0OiAwOwp9CgojbGFzdHJlc2l6ZSB7 CiAgICBwb3NpdGlvbjogYWJzb2x1dGU7CiAgICBib3JkZXI6IDE1cHggZG90dGVkIGJsdWU7Cgog ICAgdG9wOiAwOwogICAgbGVmdDogMDsKfQoKI2V4dGVudCB7CiAgICBwb3NpdGlvbjogYWJzb2x1 dGU7CiAgICBib3JkZXI6IDEwcHggc29saWQgcmVkOwoKICAgIHRvcDogMDsKICAgIGxlZnQ6IDA7 CiAgICBib3R0b206IDA7CiAgICByaWdodDogMDsKfQoKI2xvZyB7CiAgICBmb250LXNpemU6IDlw dDsKICAgIHBhZGRpbmc6IDIwcHg7Cn0KPC9zdHlsZT4KPHNjcmlwdD4Kd2luZG93Lm9ucmVzaXpl ID0gZnVuY3Rpb24gKCkgewogICAgbG9nKCJyZXNpemUiKTsKICAgIGRvY3VtZW50LmdldEVsZW1l bnRCeUlkKCJsYXN0cmVzaXplIikuc3R5bGUud2lkdGggPSB3aW5kb3cuaW5uZXJXaWR0aCArICJw eCI7CiAgICBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgibGFzdHJlc2l6ZSIpLnN0eWxlLmhlaWdo dCA9IHdpbmRvdy5pbm5lckhlaWdodCArICJweCI7Cn0KCndpbmRvdy5vbm9yaWVudGF0aW9uY2hh bmdlID0gZnVuY3Rpb24gKCkgewogICAgbG9nKCJvcmllbnRhdGlvbmNoYW5nZSIpOwogICAgZG9j dW1lbnQuZ2V0RWxlbWVudEJ5SWQoImxhc3RvcmllbnRhdGlvbmNoYW5nZSIpLnN0eWxlLndpZHRo ID0gd2luZG93LmlubmVyV2lkdGggKyAicHgiOwogICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQo Imxhc3RvcmllbnRhdGlvbmNoYW5nZSIpLnN0eWxlLmhlaWdodCA9IHdpbmRvdy5pbm5lckhlaWdo dCArICJweCI7Cn0KCmZ1bmN0aW9uIGxvZyhyZWFzb24pIHsKICAgIGRvY3VtZW50LmdldEVsZW1l bnRCeUlkKCJsb2ciKS5pbm5lckhUTUwgPSByZWFzb24gKyAiOiAiICsgd2luZG93LmlubmVyV2lk dGggKyAiICIgKyB3aW5kb3cuaW5uZXJIZWlnaHQgKyAiPGJyLz4iICsgZG9jdW1lbnQuZ2V0RWxl bWVudEJ5SWQoImxvZyIpLmlubmVySFRNTDsKfQo8L3NjcmlwdD4KPGRpdiBpZD0ibG9nIj48L2Rp dj4KPGRpdiBpZD0iZXh0ZW50Ij48L2Rpdj4KPGRpdiBpZD0ibGFzdG9yaWVudGF0aW9uY2hhbmdl Ij48L2Rpdj4KPGRpdiBpZD0ibGFzdHJlc2l6ZSI+PC9kaXY+