New issue
Advanced search Search tips

Issue 906516 link

Starred by 2 users
Status: Available
Owner:
atotic@chromium.org
Cc:
bokan@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

[LayoutNG] position:fixed Elements scroll while url bar is transitioning to hidden

Project Member Reported by atotic@chromium.org, Nov 19 
I am about to land the CL which partially fixes positioning of
position:fixed bottom:0 Elements when url bar is hidden.

https://chromium-review.googlesource.com/c/chromium/src/+/1341127

There is one remaining problem: 

While url bar is transitioning to hidden, position:fixed, bottom:0 element does
not stick to the bottom of the viewport. It gets positioned correctly
after transition ends.

I asked @skobes for a hint, and he said:
>
> I'd start with cc::LayerPositionConstraint.
> https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/page/scrolling/scrolling_coordinator.cc?q=set_is_fixed_to_bottom_edge

I tried reading this code for something obvious, without success.

I tried tracing it in gdb on my linux box. In my simple page:
<div class="fixed" style="bottom:0">fixed <span id="height"></span></div>

ScrollingCoordinator::UpdateLayerPositionConstraint only gets called for #document 
layer.

Any hints on how to debug this, where to look?

Comment 1 by bokan@chromium.org, Nov 20

Cc: -atotic@chromium.org bokan@chromium.org
Owner: atotic@chromium.org
Status: Assigned (was: Untriaged)
Yeah, so this'll be a problem in CC. The way position: fixed elements work is they're positioned by Blink when we resize the RenderWidget. However, while the user is moving the URL bar, we don't actually resize the widget (for performance reasons), we just do some slight-of-hand in CC to push around bottom-fixed Elements and expand/contract clipping layers. Seems like the CC side isn't doing this for some reason.

skobes@ is right that LayerPositionConstraint is a starting point here. That gets set on a CC layer to tell it that it needs to be bottom/top/left/right-fixed. From there, we use that in the PropertyTreeBuilder to create a transform node for the layer [1]. If it's fixed to the viewport, i.e. "affected by outer viewport bounds delta", we'll add some translation to this transform node when the URL bar moves to counter the hiding/showing direction and keep fixed elements in place.

The bounds delta (this is the amount that we need to adjust in CC by to compensate for the fact that Blink hasn't been resized) is set in LayerTreeHostImpl::UpdateViewportContainerSizes [2]. You can print out the CC side property trees by using --vmodule=layer_tree_host=3.

However, this shouldn't be affected by Blink-side changes like LayoutNG, as long as you're setting the LayerPositionConstraint correctly. Double check that fixed elements are getting a CC-side layer? This should always be the case on Android, I think. Make sure that layer gets the correct LayerPositionConstraint and that it creates a transform node gets set as being affected by the outer viewport bounds delta in PropertyTreeBuilder. 

Let me know if you're still stuck after that.

[1] https://cs.chromium.org/chromium/src/cc/trees/property_tree_builder.cc?sq=package:chromium&g=0&l=556
[2] https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?sq=package:chromium&g=0&l=2502

Comment 2 by atotic@chromium.org, Nov 26

Status: Available (was: Assigned)
Current NG code only fails in one special case:

If both top and bottom are specified, but height is not:

<div 
  style="position:fixed;bottom:0;top:200px;width:100vw;background:yellow">
</div>
►

Sign in to add a comment