Closed
Bug 1515980
Opened 6 years ago
Closed 3 years ago
Make viewport sizing in the presence of URL bar transitions consistent with other browsers
Categories
(Core :: Layout, defect, P3)
Tracking
()
RESOLVED
FIXED
Webcompat Priority | P3 |
People
(Reporter: daniel+bugzilla, Assigned: hiro)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [geckoview:p3])
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.
Reporter | ||
Updated•6 years ago
|
Blocks: viewport-compat
Comment 1•6 years ago
|
||
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.
Component: General → Layout
Product: Firefox for Android → Core
Summary: Viewport size handling is still inconsistent with Chrome Android → Make viewport sizing in the presence of URL bar transitions consistent with other browsers
Version: Firefox 65 → 65 Branch
Comment 2•6 years ago
|
||
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•6 years ago
|
||
(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•6 years ago
|
||
Well, the Chrome team think their layout is buggy: https://bugs.chromium.org/p/chromium/issues/detail?id=700431
Comment 5•6 years ago
|
||
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.
Updated•6 years ago
|
See Also: → https://webcompat.com/issues/27820
Assignee | ||
Comment 6•5 years ago
|
||
P3 for now, I assume GeckoView wants this at some point.
Priority: -- → P3
Assignee | ||
Comment 7•5 years ago
|
||
I am going to work on this. This will be split off into smaller bugs, but I am not sure yet, at this moment.
Assignee: nobody → hikezoe.birchill
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Updated•5 years ago
|
OS: Unspecified → Android
Whiteboard: [geckoview:p3]
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•4 years ago
|
![]() |
||
Updated•3 years ago
|
Webcompat Priority: --- → ?
![]() |
||
Comment 9•3 years ago
|
||
Hiroyuki-san, do you know if it's still happening?
Webcompat Priority: ? → P3
Flags: needinfo?(hikezoe.birchill)
Assignee | ||
Comment 10•3 years ago
|
||
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.
Flags: needinfo?(hikezoe.birchill)
Assignee | ||
Updated•3 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•