1917984 - Fixed-position elements are misaligned when you return to Firefox via app-switcher

Status: NEW

(Firefox for Android :: Toolbar, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:

1. View either of these testcases (from bug 1912854):
   https://bug1912854.bmoattachments.org/attachment.cgi?id=9419989
   https://bug1912854.bmoattachments.org/attachment.cgi?id=9419991
2. Scroll down so that the dynamic toolbar disappears.
3. Switch to another app (e.g. swipe the very bottom edge of your screen to the left or right, if you have that system gesture enabled)
4. Switch back to Firefox.

ACTUAL RESULTS:
When you come back to Firefox, the top-aligned (and/or bottom-aligned) edges of the fixed-position elements are shifted towards the center of the screen. They're positioned as if the fixed-position containing block were at its "smaller" size (as if the dynamic toolbar were visible or animating on/off-screen).

EXPECTED RESULTS:
No such shifting (or shrinking of the fixed-position viewport). The content should look as it did before you switched apps.

Comment 1

[Daniel Holbert [:dholbert]]

This goes back a ways; I can reproduce in Nightly 2024-09-10 as well as in Firefox release 129.0.2.

(As noted in bug 1917978 comment 0, there's a range of Nightlies that hit a worse version of this bug -- essentially manifesting the same but without requiring the app-switch (STR step 3 here). But that worse version has been fixed as of today, and was tracked in bug 1912854.)

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

[Botond Ballo [:botond]]

Based on the symptoms, this is likely an issue in the GeckoView or Fenix layer with the usage of dynamic toolbar related APIs like setVerticalClipping around app switching.

Comment 4

[Chris Peterson [:cpeterson]]

Petru, what priority do you think we should give this bug?

It's not related to the new navbar. Daniel says this is not a new bug. It's reproducible at least as far back as Firefox 129.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Chris Peterson [:cpeterson] from comment #4)

Daniel says this is not a new bug. It's reproducible at least as far back as Firefox 129.

[Testing a bit further back just for completeness]: I can reproduce this bug in the oldest Fenix Nightly that I have available for testing (in my local mozregression cache), which is Fenix Nightly 97.0a1 2021-12-21

Comment 6

[Petru-Mugurel Lingurar [:petru]]

Looking a bit into this I saw that we are indeed calling setVerticalClipping whenever getting back to the application but with the same value as last used when in the app.
This seems like the only update that we make and it's not something that can easily be avoided for this specific scenario - we update this value as part of the general functionality for the dynamic toolbar.

Giving that this is an old visual bug which reproduces in a specific scenario with a workaround available I'd put this on the backlog for issues to be fixed by switching to a new way to animate the toolbar.

Comment 7

[Petru-Mugurel Lingurar [:petru]]

LE: I hacked a workaround for this specific scenario

whenever getting back to the application but with the same value as last used when in the app

to not call setVerticalClipping with the same value as before and the issue still reproduces.