|Summary:||Viewport height is taller than the visible part of the document in some mobile browsers|
|Product:||WebKit||Reporter:||Nicolas Hoizey <nicolas>|
|Severity:||Normal||CC:||benjamin, bokan, bruno, daytonlowell, johnpmeyer, marsjaninzmarsa, rbyers, robert.vuj.linder, sabberworm, sheerun, simon.fraser, staffan.ekberg76, toldede, tomac, webkit-bug-importer, webkit, wensink.tim, yoav|
|Version:||528+ (Nightly build)|
Description Nicolas Hoizey 2015-02-20 02:40:04 PST
Comment 1 Nicolas Hoizey 2015-02-20 02:40:38 PST
Created attachment 246953 [details] Bottom hidden in iOS Safari in portrait mode
Comment 2 Nicolas Hoizey 2015-02-20 02:41:10 PST
Created attachment 246954 [details] Full content visible in iOS Safari in portrait mode after scroll
Comment 3 Nicolas Hoizey 2015-02-20 02:41:32 PST
Created attachment 246955 [details] Bottom hidden in iOS Safari in landscape mode
Comment 4 Nicolas Hoizey 2015-02-20 02:42:02 PST
Created attachment 246956 [details] iOS Safari in landscape mode goes full screen after scroll
Comment 5 Benjamin Poulain 2015-02-23 09:25:58 PST
This is completely intentional. It took quite a bit of work on our part to achieve this effect. :) The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS). It is hard to show you the "looks like shit" part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting. Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size. From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.
Comment 6 Nicolas Hoizey 2015-02-23 09:32:26 PST
Thanks for the explanation. I suppose I will have to use JS instead of CSS for positioning the interface elements and adjust according to the "real" viewable area… :-/
Comment 7 Benjamin Poulain 2015-02-23 09:47:32 PST
Comment 8 David Bokan 2015-11-30 10:28:07 PST
(In reply to comment #5) > This is completely intentional. It took quite a bit of work on our part to > achieve this effect. :) > > The base problem is this: the visible area changes dynamically as you > scroll. If we update the CSS viewport height accordingly, we need to update > the layout during the scroll. Not only that looks like shit, but doing that > at 60 FPS is practically impossible in most pages (60 FPS is the baseline > framerate on iOS). > > It is hard to show you the "looks like shit" part, but imagine as you > scroll, the contents moves and what you want on screen is continuously > shifting. > > Dynamically updating the height was not working, we had a few choices: drop > viewport units on iOS, match the document size like before iOS 8, use the > small view size, use the large view size. > > From the data we had, using the larger view size was the best compromise. > Most website using viewport units were looking great most of the time. Hi Benjamin, sorry to resurrect this old bug, but I'm working on improving interop between Chromium and Safari here and the choice to use the larger view size seems strange given that the ICB uses the smaller view size. In particular, this means height:100% and height:100vh will be different which might be surprising. Did you intentionally make the ICB and 100vh unequal? Do you have any examples of pages that look better using this method? Thanks, David
Comment 9 Rick Byers 2016-01-25 07:49:31 PST
Note that blink is planning on matching WebKit's behavior here, but it's causing some developer concern. Details: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4 https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/EBNboiECIAQ It's still not at all clear this is really the right design for the web long-term. Perhaps there's a missing API somewhere?
Comment 10 John Meyer 2016-04-27 16:55:10 PDT
It seems to me that the original intent to not reflow while scrolling was a good idea. However, the divergence of height: 100% and height: 100vh breaks the principal of least astonishment at the very least. Rather than choose the largest or smallest icb, I believe users and developers would expect the viewport size to not change at all while scrolling. However, when the scrolling is complete, the viewport should be updated and the elements reflowed. I realize that reflowing the document after the user has finished scrolling is challenging due to potential changes in scroll position, but maintaining the expected scroll position should be doable. This would allow developers to use 100vh and have it most closely resemble the spec while keeping the desired performance.
Comment 11 hexalys 2016-04-28 16:58:21 PDT
(In reply to comment #9) > Note that blink is planning on matching WebKit's behavior here, but it's > causing some developer concern. Details: > > It's still not at all clear this is really the right design for the web > long-term. Perhaps there's a missing API somewhere? As a dev, the important part is to at least, be able to detect the difference in px via JS. For my own use so far, I have managed to detect the dynamic iOS Safari bar and its size; using a generic debounced resize|scroll event, which updates a CSS class on the document. That give me CSS class updating CSS height accordingly using `calc`. But it remains a fragile hack relying on quite a few assumptions. The current behavior, *if detectable*, has a significant benefit. This can allow for example, adding a bottom notifications, messages or button bar. But not until a scroll has occurred, and the bottom menu bar is gone; to avoid redundant double bars and/or not to clutter screen space. As for an API, HTML5 has the BarProp interface for this kind of thing. It seems however that browsers have moved away from exposing any useful values for those attributes, to the point of no longer exposing anything at all on mobile browsers. It seems appropriate to review what BarProp is, what to keep, redefine or add, such as pixel values. Or else BarProp might as well be deprecated... But if 100vh is context dependent, the browser *should* surely expose that behavior somewhere.
Comment 12 David Bokan 2016-04-29 11:15:46 PDT
(In reply to comment #10) > It seems to me that the original intent to not reflow while scrolling was a > good idea. However, the divergence of height: 100% and height: 100vh breaks > the principal of least astonishment at the very least. Rather than choose > the largest or smallest icb, I believe users and developers would expect the > viewport size to not change at all while scrolling. However, when the > scrolling is complete, the viewport should be updated and the elements > reflowed. This is perhaps less astonishing to developers, but to users can be quite frustrating if the developer hasn't thought about it. For e.g., I've seen examples that use vh units to size fonts, which works quite nicely on desktop. On mobile, the page becomes exceedingly annoying as everything resizes and reflows on each change of direction. > I realize that reflowing the document after the user has finished scrolling > is challenging due to potential changes in scroll position, but maintaining > the expected scroll position should be doable. This would allow developers > to use 100vh and have it most closely resemble the spec while keeping the > desired performance. Anchoring the scroll position on relayout is tricky but doable and Chrome's actively working on this. Even if that works perfectly though, I still think that we should make the layout height static *by default*. Exposing this information is a good idea, and we plan to keep window.innerHeight reflecting the status of the top controls (as Safari does IIRC) for motivated developers to make use of it. But I see a static layout as a "pit of success". If a developer doesn't think about this, the default doesn't cause the user a poor experience (even with non-visible differences, constantly changing the layout size causes increased power draw on mobile). If the dev does think about it, they should have the tools to design an even better user experience.
Comment 13 tolga dede 2017-10-30 07:37:43 PDT
cut the shit. this is clearly a FUCKING BUG and NEEDS TO BE FIXED.
Comment 14 Staphan 2018-01-05 07:01:51 PST
I realize that the WebKit developers aren't interested in supporting standards, but what is the correct in getting the correct height in poorly designed browsers such as WebKit? Why aren't the developers interested in supplying a way to actually get the height of the content pixels?
Comment 15 Tim 2018-06-08 06:01:30 PDT
Comment 16 RobLi 2018-06-28 11:13:53 PDT
There may be a solution for this if there is an env() variable defined, as suggested here: https://github.com/w3c/csswg-drafts/issues/2630#issuecomment-397536046 If UA's would define their "overlayed" interfaces we could just inset the HTML document.
Comment 17 Adam Stankiewicz 2019-02-04 12:58:18 PST
We cannot easily use calc with 100vh on Safari because of this... Pretending that vertical height of viewport is not changing when it is causes lots of headaches for developers who need to hack their applications just for Safari on iOS because it has issues with calc(100vh - xxx) CSS calculations. Please re-open this issue
Comment 18 Adam Stankiewicz 2019-02-04 12:58:49 PST
Here's article with more info: https://benfrain.com/the-ios-safari-menu-bar-is-hostile-to-web-apps-discuss/
Comment 19 Simon Fraser (smfr) 2019-02-04 13:00:23 PST
We may revisit this.