Open Bug 1594451 Opened Last month Updated 17 days ago

The bottom banner on ignores the dynamic toolbar


(GeckoView :: General, defect, P2)



(firefox72 affected)

Tracking Status
firefox72 --- affected


(Reporter: jonalmeida, Assigned: hiro)


(Blocks 1 open bug)



(1 file)

From bug 1516048#c22, the banner for cookies/privacy banner for the homepage doesn't follow along with the dynamic toolbar when scrolling.

This might be the same case for as well. See attached screenshot for both cases.

The banner on is a position:sticky element and it's correctly positioned with patches for bug 1586144, but it doesn't stick to the bottom when scrolling down the content. So maybe we are referring a wrong scroll layer there?

This bug is a blocker for re-enabling Fenix's dynamic nav bar.

Depends on: 1586144
Priority: -- → P1
Summary: The banner on ignores the dynamic toolbar → The bottom banner on ignores the dynamic toolbar
Rank: 2
Priority: P1 → P2

The patches in bug 1552608 only handle position:fixed elements. position:sticky will need some additional work.

Outline of the work needed to support position:sticky:

  • Propagate the layer attributes related to position:sticky (GetIsStickyPosition(), GetStickyScrollContainerId(), GetStickyScrollRangeOuter(), GetStickyScrollRangeInner()) to LayerMetricsWrapper and WebRenderScrollDataWrapper. (The WebRenderScrollDataWrapper implementations may or may not need to be filled in, depending on the approach taken in bug 1583380.)
  • Propagate the sticky attributes further to HitTestingTreeNode.
  • Revise APZCTreeManager::IsFixedToRootContent() to be IsFixedOrStuckToRootContent() which checks "is the element fixed to the root OR is the element sticky and currently stuck to the root". The "is currently stuck" part is somewhat tricky; it will involve querying the sticky scroll container ID, finding the corresponding APZC, and comparing its scroll offset to the inner and outer sticky ranges.

It looks like GetFixedPosSides() is already populated for sticky elements, so nothing further needs to be done there.

With the instruction what Botond provided in comment 4, I think I can fix this.

Assignee: nobody → hikezoe.birchill
You need to log in before you can comment on or make changes to this bug.