vh units in position: fixed element are not static relative to the URL bar |
||
Issue descriptionChrome 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.
,
Sep 11
+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)
,
Sep 11
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?
,
Sep 12
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?
,
Sep 12
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.
,
Dec 17
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 |
||
Comment 1 by bokan@chromium.org
, Sep 11