1917978 - Fixed-position headers which are attached to both top and bottom detach from the edge of the screen while dynamic toolbar is animating on/offscreen

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Load https://bug1912854.bmoattachments.org/attachment.cgi?id=9419989
2. Scroll down.

EXPECTED RESULTS:
As the dynamic toolbar scrolls out of view, the header should remain snapped to the top of the screen.

ACTUAL RESULTS:
As the dynamic toolbar scrolls out of view, the header shifts downwards towards the center of the page. Then when the dynamic toolbar entirely disappears, the header snaps back to the top of the screen.

NOTES
The linked testcase is "testcase 1" from bug 1912854, but this bug goes back further than that bug -- i.e. it affects official Firefox release 129.0.2 (and probably further back too). There are a range of nightlies that experience a worse bug (bug 1912854 specifically) where the header bar remains detached - that's fixed as of today, though, so we're back to a state where the header simply detaches temporarily.

It looks like maybe what's happening is: as we transition to having a larger viewport, we vertically-center the "old" fixed-position-containing-block within whatever our current intermediate screen size is; and then we do a clean switch when we've arrived at the final viewport size. Chrome does something like this too, but they don't vertically-center -- they seem to just snap the "old" fixed-position containing block to the top of the screen as their dynamic toolbar is animating away.

Comment 1

[Daniel Holbert [:dholbert]]

The overall behavior is perhaps a bit easier to see with testcase 2 from bug 1912854:
https://bug1912854.bmoattachments.org/attachment.cgi?id=9419991

• In Firefox, the giant fixed-pos cyan element (with an orange border) stays the same "smaller" size as you start to scroll the dynamic toolbar out of view, and then it snaps to be full-size when the toolbar fully hides. We reverse this process exactly when you start to scroll the dynamic toolbar back into view -- first the giant cyan element snaps to be the "smaller" size and gets vertically centered with space above and below it, and that space gradually shrinks as you scroll the dynamic toolbar fully into view. Throughout this whole process, the cyan element seems to be vertically centered in the instantaneous "user-exposed" viewport (so there's blank space above and below the cyan element for all of the intermediate states where it's the "smaller" size and the user-exposed viewport is somewhat larger).

• In Chrome, the giant cyan element is always snapped to the top of the screen (i.e. the "top:0" is paramount), but otherwise behaves similarly to Firefox. It stays the same "smaller" size (but snapped to the top) as the toolbar starts to hide; this means some space is created below it (at the bottom of your screen) as the toolbar is animating away. Then it snaps to the larger size once the toolbar is fully hidden. If you then scroll back up to reveal the toolbar, Chrome keeps the cyan element at the larger size (meaning its bottom edge gets clipped) until the toolbar is fully in view.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Markus Stange [:mstange]]

I think this is caused by this branch in ComputeFixedMarginsOffset:

https://searchfox.org/mozilla-central/rev/abe6e3de6850eca664e968484f8ecfc53487ea42/gfx/layers/apz/src/APZUtils.cpp#60-61

if ((aFixedSides & SideBits::eTopBottom) == SideBits::eTopBottom) {
  translation.y += (effectiveMargin.top - effectiveMargin.bottom) / 2;

For elements which are attached to the top and bottom, this code tries to keep them centered in the expanded viewport.

I think we should just change it to make it so elements which are attached to both top and bottom act as if they were only attached to the top. This matches what layout does if you overconstrain the height by setting top, bottom and height - the bottom value is ignored.

Comment 4

[Markus Stange [:mstange]]

Attachment: Bug 1917978 - Don't attempt to center fixed elements when the viewport size changes due to dynamic toolbars. r=botond

Comment 5

[Markus Stange [:mstange]]

Botond, do you know of any tests which might depend on the previous behavior?

Comment 6

[Markus Stange [:mstange]]

I guess I should add a test for this. It can probably just be a copy of dynamic-toolbar-fixed-top-1.html with bottom added.

Comment 7

[Botond Ballo [:botond]]

(In reply to Markus Stange [:mstange] from comment #5)

Botond, do you know of any tests which might depend on the previous behavior?

I don't. I traced the code back to bug 1214267 where Kats added it in this patch, but there was no rationale given for this behaviour, and no accompanying test cases added.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5aa25fef7934
Don't attempt to center fixed elements when the viewport size changes due to dynamic toolbars. r=botond

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/5aa25fef7934