1515980 - Make viewport sizing in the presence of URL bar transitions consistent with other browsers

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[daniel+bugzilla]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Viewed a webpage that had an element height based on viewport height (i.e. height: 100vh)


Actual results:

Viewport height changes when scrolling down because the url bar disappears. Initial containing block size also changes due to the hiding of the url bar.


Expected results:

Viewport height should be consistent with chrome and ignore the presence of the URL bar. Initial containing block size should assume that the url bar is always present. This brings firefox in line with the behavior of chrome and ios on mobile. For more information see this Github repo: https://github.com/bokand/URLBarSizing.

Comment 1

[Botond Ballo [:botond]]

Thanks for the report!

I'm going to move this into the Layout component, although the work will likely involve changes to both Layout code and the Android front end.

Also cc'ing Eitan who has been doing some work on the hiding URL bar in Focus+GeckoView.

Comment 2

[Eitan Isaacson [:eeejay]]

Yup. This would be awesome. Right now, GeckoView doesn't even limit the ICB to the visible area in android-compontents or Focus, so I would say that is a first step. I have a WIP for this bug, but it is probably wrong. Might leave this for the Layout People :)

Comment 3

[Botond Ballo [:botond]]

(In reply to Eitan Isaacson [:eeejay] from comment #2)
> Right now, GeckoView doesn't even limit the ICB
> to the visible area in android-compontents or Focus

Depending on the page, that may be intentional. The ICB isn't always meant to be limited to the visible area, particularly in the presence of zooming, or certain values in the meta viewport tag. See this document (where the visible area would be the "visual viewport"):

https://github.com/bokand/bokand.github.io/blob/master/web_viewports_explainer.md#definitions

Comment 4

[Mats Palmgren (inactive)]

Well, the Chrome team think their layout is buggy:
https://bugs.chromium.org/p/chromium/issues/detail?id=700431

Comment 5

[David Bokan]

The bug in Chrome is just with vh units in a position: fixed context. In that case we want 100vh to behave the same as 100% and resize based on the fixed viewport size (which will increase in height as the URL bar hides). For non-fixed layout, 100vh should be static so that hiding the URL bar doesn't change its size.

The reason for position: fixed causing vh and % to resize (other than compatibility with Safari) was that fixed items tend to want to be sized relative to the viewport. Not-resizing them would cause menus and the like to have a gap when the user hides the URL bar. For in-flow content, resizing them causes jarring reflows as the user scrolls so we avoid resizing the ICB.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

P3 for now, I assume GeckoView wants this at some point.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

I am going to work on this. This will be split off into smaller bugs, but I am not sure yet, at this moment.

Comment 9

[Karl Dubost💡 :karlcow]

Hiroyuki-san, do you know if it's still happening?

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Thank you Karl for doing ni to me about this. Indeed in the original reporter's intention that is "vh units should not be changed by the dynamic toolbar transition" is no longer an issue in our implementation. Though there are some corner cases such as bug 1641166, I will move them to block bug 1123938 and close this bug.