New issue
Advanced search Search tips

Issue 700431 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

vh units in position: fixed element are not static relative to the URL bar

Project Member Reported by bokan@chromium.org, Mar 10 2017

Issue description

Chrome Version: 59.0.3037.0
OS: Android

What steps will reproduce the problem?
(1) Visit https://bokand.github.io/demo/urlbarsize.html
(2) Scroll down to hide the URL bar

What is the expected result?
The "viepwort unit position: fixed" bar should match the visual viewport, resizing when the URL bar is hidden. It should behave the same as the "percentage-based position: fixed" bar.

What happens instead?
It behaves the same as "viewport-unit position: absolute" bar. That is, 100vh is taller than the viewport if the URL bar is showing. 

Please use labels and text to provide additional information.


For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 
Cc: bokan@chromium.org
 Issue 882283  has been merged into this issue.
Cc: -bokan@chromium.org futhark@chromium.org
+futhark: I took a deeper look here but I'm not sure what the right way to fix this is.

When an element is or is inside a position: fixed tree, we want 100vh to resize along with the URL bar. This should match %-based heights which get their size from the static (w.r.t. the url bar) ICB if they're non-fixed, and the actual viewport size (i.e. the FrameView's frame rect) if they are fixed.

It looks like we get and store the viewport size for vh units during style recalc. At this point, we don't yet know we're in a fixed-position element though, let alone a subtree. Is there a good way to do this from style or should we apply a special case in layout for this?

(for context, see https://developers.google.com/web/updates/2016/12/url-bar-resizing)
Actually, a special case in layout sounds bad since vh can be used in all sorts of places. Can we make it so that viewport size resolution happens after we've determined whether we're in a fixed subtree?
You can figure out if you're in a fixed subtree if you walk up ancestor computed styles, I guess. Inheriting a custom flag down computed styles in not ideal as that will cause subtree recalcs where we currently don't have (position changing). It's possible to lazily figure out if we are in a fixed subtree when we try to resolve viewport units by walking the flat tree ancestors' computed style for position:fixed.

I think that would mean keeping track of this down/up RecalcStyle() somehow, without needing to walk the ancestor chain every time. Similarly to pushing selector filters.

Do we already have the functionality in place for marking style dirty when the URL bar moves?

It's possible to just read the position() value out of ComputedStyle as you walk down the tree, but I suspect you'll see that affect performance doing small changes deep down an otherwise clean tree.

What if vw functionality was reverted to pre version 56 and a new "display height" was added that acts as vh currently does.  That way vh would work in a way that makes sense and there would be a unit that stays the same regardless of whether or not the menu bar is shown.

Sign in to add a comment