1914831 - In maximized Private Browsing window, the tabstrip continuously jiggles side to side

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect, P2)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Open a private browsing window.
2. Maximize the window.
3. Look at the tabstrip.

ACTUAL RESULTS:
The tabstrip is continously jiggling left and right, all on its own, as fast as it possibly can. It kinda looks like it's a superposition of two layouts.

EXPECTED RESULTS:
No such jiggling.

Mozregression says this is a regression from bug 1913322.

This reproduces for me on a fresh profile, but only on one machine so far. That machine is a MS Surface Pro 7+ running Ubuntu 24.04, using 2736x1824 resolution and 200% pixel scaling in Ubuntu's display settings.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Here's a screencast showing the bug. It doesn't really do the bug justice since the screencast's frame rate isn't fast enough to fully capture the jiggling, but you can see it to some extent. Just take my word for it that the private browsing window's tabstrip is furiously wiggling between the two positions shown here as rapidly as it possibly can.

Comment 2

[Daniel Holbert [:dholbert]]

profile: https://share.firefox.dev/3XfPit8

The marker chart is extremely busy. Not sure which markers are the root causes & which are just symptoms, but one possible clue: the "DOMEvent" track seems to show that we're alternating between an underflow event and then an overflow event (over and over). Perhaps we're responding to one in some way, to avoid {under/over}-flowing, and we end up overshooting and triggering the other one, and we respond to that, and this repeats forever?

Comment 3

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

Set release status flags based on info from the regressing bug 1913322

:emilio, since you are the author of the regressor, bug 1913322, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Alice0775 White]

This problem can be reproduced even in normal sizemode when a Private window has a certain window width on ubuntu22.04.
And I got a same regression window above.

See screencast: https://youtu.be/VkMEJg3pM4s

Comment 5

[Alice0775 White]

And in Windows11, I can see the unwanted scroll buttons at both side of tab strip at certain width of Private window.
This could be the same cause.

See screencast: https://youtu.be/rmMzd7iZsbE

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Yeah, I can get to a state where:

temp0.clientWidthDouble // 1188.9832763671875
temp0.firstChild.getBoundingClientRect().width // 1188.9833984375

This is because DOMRect rounds differently than anything else.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1914831 - Misc clean-ups to our DOMRect and rounding code. r=#layout

No behavior change.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1914831 - Try to use consistent rounding in DOMRect::SetLayoutRect. r=#layout

Otherwise we can get into states where identical numbers end up being
different from the ones exposed in other APIs.

This is a somewhat risky change, so gate it behind a pref.

This fixes the issue, but given it's a tricky change I'll also add a
workaround to avoid depending on it on the front-end.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1914831 - Allow tiny differences in our values to not trigger our overflow state. r=dao

See the comment.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e31db23e50ee
Misc clean-ups to our DOMRect and rounding code. r=longsonr

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/75588bc18622
Try to use consistent rounding in DOMRect::SetLayoutRect. r=longsonr
https://hg.mozilla.org/integration/autoland/rev/d794404ec2a2
Allow tiny differences in our values to not trigger our overflow state. r=dao,longsonr

Comment 12

[tszentpeteri]

Backed out 75588bc18622 for causing unforeseen failures as requested by Emilio.

• Backout link

Comment 13

[Phabricator Automation]

Comment on attachment 9420791 [details]
Bug 1914831 - Try to use consistent rounding in DOMRect::SetLayoutRect. r=#layout

Revision D220126 was moved to bug 1914970. Setting attachment 9420791 [details] to obsolete.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Thanks, moved it to bug 1914970.

Comment 15

[Daniel Holbert [:dholbert]]

FWIW, I just manually verified that the remaining patch (https://hg.mozilla.org/integration/autoland/rev/d794404ec2a2 / https://phabricator.services.mozilla.com/D220127 ) does indeed fix this issue for me.

(I'm testing with a local debug build from yesterday's mozilla-central, which repro's the issue with my steps in comment 0, but does not repro if I manually apply d794404ec2a2's raw patch file and rebuild.)

Comment 16

[Phabricator Automation]

Comment on attachment 9420791 [details]
Bug 1914831 - Try to use consistent rounding in DOMRect::SetLayoutRect. r=#layout

Revision D220126 was moved to bug 1914970. Setting attachment 9420791 [details] to obsolete.

Comment 17

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/d794404ec2a2

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/e31db23e50ee

Comment 19

[Monica Chiorean]

I was able to reproduce the issue on Ubuntu24.04 using Firefox build 131.0a1(20240826094418).
Verified as fixed on Ubuntu24.04/Win11x64 using Firefox builds 132.0a1(20240923090434) and 131.0b9.