Optimize window.innerWidth/window.innerHeight to not cause layout where possible |
||||||
Issue descriptionOn platforms without scrollbars it should be possible to calculate the dimensions of a window without causing layout. Apps may want to make decisions based on viewport size early in their lifecycle. As it stands this requires them to force an early layout, only to use the resulting data to really render the page, which then causes another layout. From esprehn@ on chat: "bizarrely you can use window.outerHeight and it looks like it doesn't cause a layout but then you need to subtract the toolbar height which we don't tell you also it looks like window.innerHeight doesn't actually need to cause a layout, this code is trying to compute the entire rect, and we need to know scroll offsets to know the whole rect there's various code in the engine like this where we compute x,y,width,height when we only need to know width/height and could do it faster another case were apparently knowing the viewport size requires knowing the layout is autosize mode, which is an Android WebView feature, and also used for extension popups." My understanding is that in the common case on Android (Chrome Browser), accessing window dimensions should be essentially free at all times; including for iframes where the last parent window layout should provide all required info.
,
Oct 15 2016
,
Oct 17 2016
,
Oct 18 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 18 2017
,
Jul 27
,
Jul 31
Dave, what was your idea to avoid the layout here? Was it just prevent the layout call after the load event has been dispatched? I'm not sure that's as straightforward as we thought. Consider: https://bokand.github.io/innerwidth.html When you click the button, we add a 1200px box that expands the layout viewport size (and zooms out as a result) and prints out the innerWidth. I think with your optimization we'd print out the wrong layout size here. I've been discussing on and off with (primarily) Mozilla and Apple engineers changing it to remove this problematic dependency on content width (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1123938#c38). Post-load event, I'm not why anyone would rely on this esoteric behavior (not sure anyone outside a handful of browser engineers even understands it) so I'd be ok making this change, but realize this does have potential compat impact. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by bokan@chromium.org
, Oct 14 2016