2027911 - When tapping Private Browsing button on home-screen, the homescreen UI jumps upwards for a moment (causing visual jitter and possible mis-directed taps)

Status: VERIFIED FIXED

(Firefox for Android :: Homepage, defect)

Description

[Daniel Holbert [:dholbert]]

Steps to reproduce

1. Open a new tab (viewing the Nightly new-tab home page)
2. Repeatedly tap the Private Browsing button at the top right corner, to switch into & out-of private browsing mode. Watch the top of your screen carefully.

Expected behavior

Should toggle back and forth between private browsing mode.

Actual behavior

• As I'm toggling back and forth, I sometimes see the home page content briefly jump upwards into the toolbar area.
• This isn't just visual; it also puts the "Show All" topsites-link directly underneath my finger, where the Private Browsing toggle-button recently was -- so if I tap that area rapidly, I unexpectedly am taken to the Top Sites "Show All" area (and then possibly on from there to whatever Top Site occupies that portion of the Show All screen, which in my case is Wikipedia)

Device information

• Firefox version: Nightly 151.0a1
• Android device model: Pixel 4a, Pixel 10 Pro XL
• Android OS version: 13 (on Pixel 4a), 16 (on Pixel 10 Pro XL)

Any additional information?

This is a recent regression, with this regression range (when bisecting on my Pixel 4a with Android 13):
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=09bbcab331fb723c4ab6316d486e2500fb8f4365&tochange=e52ef55079f792c6f0cb79aa121a119866637e1f

I'm not yet sure what in that range would be the regressor...

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: snapshot 1, from around 2s in attached screencast (showing brief rendering of broken layout on regular homescreen)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: snapshot 2, from around 4s in attached screencast (showing brief rendering of broken layout on private browsing homescreen)

Comment 4

[Daniel Holbert [:dholbert]]

Note: the above screencast/snapshots were taken using my Pixel 4a with the first-bad build (Nightly 2026-03-18) (just because that's what I had available after bisecting, when I went into "record a screencast" mode).

This bug persists in latest Nightly 2026-03-30.

Comment 5

[Daniel Holbert [:dholbert]]

I see a version of this bug in Firefox Beta 150, too. On my main phone (Pixel 10 Pro XL), Beta has a different layout at the top of the home screen (with Private Browsing button at top-left and a "News" button in top-right) -- but I see the same sort of buttons-flickering-into-toolbar-area when I toggle between private/regular mode.

Comment 6

[Daniel Holbert [:dholbert]]

I see a version of this bug in Firefox Beta 150, too. On my main phone (Pixel 10 Pro XL), Beta has a different layout at the top of the home screen (with Private Browsing button at top-left and a "News" button in top-right) -- but I see the same sort of buttons-flickering-into-toolbar-area when I toggle between private/regular mode.

Comment 7

[Daniel Holbert [:dholbert]]

(and on my Pixel 4a with a fresh install of beta150, I see basically the same behavior that I captured in the attached screencast.)

Comment 8

[Daniel Holbert [:dholbert]]

[Tracking Requested - why for this release]: Visual regression (noticeable flicker, and possibility of mis-tapped buttons) in prominent UI, the new-tab home screen

Comment 9

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox150 (beta). However, the bug still isn't assigned.

:gl, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 10

[Dianna Smith [:diannaS]]

:dholbert does this need an assignee?

Comment 11

[Daniel Holbert [:dholbert]]

Likely so, but I'm not in a position to assign someone (I work on unrelated stuff and am just the reporter here.).

Comment 12

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2027911 - Set e2e strategy for shown fragments as soon as they're attached. r=#android-reviewers

The bug report showed that the current doOnPreDraw - after the fragment's layout is built
but before it is drawn on screen - is too slow for out needs.

Moved to using doOnAttach instead that runs when that view is attached to a window - if the
view is already attached it runs immediately, otherwise it runs the next time the view attaches.
It is a one-shot callback that automatically gets disposed after the first run.

Comment 13

[Petru-Mugurel Lingurar [:petru]]

If the fix is good it should probably be uplifted to 150.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a59ef55eaa45
https://hg.mozilla.org/integration/autoland/rev/41bdc02d7cf3
Set e2e strategy for shown fragments as soon as they're attached. r=android-reviewers,tthibaud

Comment 15

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/41bdc02d7cf3

Comment 16

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:petru, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox151 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Mira Lobontiu (Android QA)]

Verified as fixed on the latest Firefox for Android Nightly 152.0a1 from 4/24 with a Samsung Galaxy S24 (Android 16), and a Pixel tablet (Android 16).
To test this scenario, I've disabled the "Private Mode and Stories Entry Point" toggle from Secret settings.

Comment 18

[Donal Meehan [:dmeehan]]

Please add uplift requests

Comment 19

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2027911 - Set e2e strategy for shown fragments as soon as they're attached.

The bug report showed that the current doOnPreDraw - after the fragment's layout is built
but before it is drawn on screen - is too slow for out needs.

Moved to using doOnAttach instead that runs when that view is attached to a window - if the
view is already attached it runs immediately, otherwise it runs the next time the view attaches.
It is a one-shot callback that automatically gets disposed after the first run.

Original Revision: https://phabricator.services.mozilla.com/D295765

Comment 20

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 2027911 - Set e2e strategy for shown fragments as soon as they're attached.

The bug report showed that the current doOnPreDraw - after the fragment's layout is built
but before it is drawn on screen - is too slow for out needs.

Moved to using doOnAttach instead that runs when that view is attached to a window - if the
view is already attached it runs immediately, otherwise it runs the next time the view attaches.
It is a one-shot callback that automatically gets disposed after the first run.

Original Revision: https://phabricator.services.mozilla.com/D295765

Comment 21

[Petru-Mugurel Lingurar [:petru]]

(In reply to Donal Meehan [:dmeehan] from comment #18)

Please add uplift requests

Thanks for the ping!
Added now uplift requests for the two small fixes, this and the one from bug 2029378 (as a stack).

Comment 22

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/563c7e8f8bfa
https://hg.mozilla.org/releases/mozilla-beta/rev/77dbec293348

Comment 23

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/f526de50b62e
https://hg.mozilla.org/releases/mozilla-release/rev/f848eeb90916

Comment 24

[Mira Lobontiu (Android QA)]

Verified as fixed on the latest Firefox for Android Beta 151.0b3, and RC 150.0.1 with a Samsung Galaxy S24 (Android 16), and a Pixel 6 (Android 17).
To test this scenario, I've disabled the "Private Mode and Stories Entry Point" toggle from Secret settings.