2057062 - Resizing window is extremely slow and laggy on Linux with Wayland when vertical tabs sidebar has many tabs open

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Jeff Fortin]

Context

This is with Firefox 152.0.6 from Fedora 44's RPM repositories, with GNOME 50.3's Wayland session running on Intel UHD Graphics 620 (Kabylake) with an Intel Core i5-8350U CPU.

My about:support is attachment #9610461 [details] (same as in bug #2056048).

This is not the same as bug #2016616 because I am testing with always-on scrollbars disabled now. It has some similarity to bug #2021898 but here I am not resizing the sidebar's width per se, I am resizing the window itself, which may influence the sidebar's height but not its width.

Steps to reproduce

1. Enable vertical tabs (window resizing is slow in general, but vertical tabs exacerbate the problem massively). In my case, the vertical tabs list sidebar is positioned to the left of the browser window.

2. Have hundreds of tabs open (they don't need to be active/loaded, they can be discarded/unloaded, but they need to be shown in the vertical tabs list). In my case, I have 15 pined tabs and about 450 regular tabs shown in the vertical tabs list.

3. Load a very simple website, like https://example.com (to rule out the website's layout being the problem)

4. Click and drag the bottom-right corner of the Firefox window.

What happened? (actual results)

It lags so much that I have the equivalent of what feels like 0.5 to 2 frames per second while resizing.

This is the profile I was able to capture with Ctrl+Shift+1's default settings: https://share.firefox.dev/3T6GkPp

Comment 1

[Jeff Fortin]

Attachment: Demonstration video with vertical tabs

This video shows how sluggish Firefox 152's window resizing is with vertical tabs, even with only 12 pinned tabs and 34 regular tabs opened in the vertical tabs sidebar.

You can see Firefox's vertical tabs UI (and web renderer) being utterly unable to keep up with the mouse cursor.

Comment 2

[Jeff Fortin]

Attachment: Demonstration video with horizontal tabs

This video with tabs set horizontally instead of vertically shows that it lags a lot less when tabs are not vertical. Still fairly laggy though.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

This is all in accessibility code. Curious, do you have a11y software working?

It points at this code.

Jamie, shouldn't that code run ContentInserted only when transform / etc changes?

Reporter, can you confirm that if you go to about:config and set accessibility.force_disabled=1 it works better?

Comment 4

[Jeff Fortin]

This is all in accessibility code. Curious, do you have a11y software working?

I don't have particular accessibility features turned on in GNOME, other than "large text" (i.e. org.gnome.desktop.interface text-scaling-factor = 1.25 font scaling, not the same as fractional HiDPI) when I'm running in laptop-only mode, but when I'm running on external monitors (which was the case during the testing here) I'm running at 1.00 normal font scaling.

In particular, I can confirm that the screen reader (Orca) is not activated nor running (no Orca process, though there is the speech-dispatcher process present, spawned by Firefox as far as I know).

Reporter, can you confirm that if you go to about:config and set accessibility.force_disabled=1 it works better?

Wow… yes, toggling that setting to 1 suddenly makes everything super fast (there's some visible jank in the window's repainting/redrawing regions during resizing, but at least the jank is fast, feels like 24 fps+).

Comment 5

[James Teh [:Jamie]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #3)

It points at this code.

What's weird to me is why this node doesn't have an Accessible in the first place. If it has one of those properties, we should have created one previously, which would mean this code would never run. I guess it must be excluded by some other condition in MustBeGenericAccessible. I'd really love to know what the nodes in question are, but the mouse aspect of this bug is infeasible for me to test as a screen reader user.

Jamie, shouldn't that code run ContentInserted only when transform / etc changes?

Ideally, yes, though the point above is why we didn't see the need to do this initially. I guess we can pass aOldComputedStyle from nsIFrame::DidSetComputedStyle. That said, I think we should sort out the issue I flagged above first.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Can you run gsettings get org.gnome.desktop.interface toolkit-accessibility and check what does it report?

Comment 7

[Jeff Fortin]

gsettings get org.gnome.desktop.interface toolkit-accessibility returns false on that laptop computer, as well as on my desktop computer.

However, I found out some new things:

• The issue does not persist through a reboot
• To trigger the bug after a reboot (on any of my computers), I simply need to launch orca (ex: with GNOME Shell's Alt+F2 command launcher); Firefox will then exhibit the lagging behavior, even if the gsetting still returns false. Then, if I run killall orca (and get the "Screenreader off" audible confirmation that Orca exited), Firefox will still remain slow in the same way (and the gsetting will still return false).

I might have launched Orca at some point in time to test accessibility in some GNOME apps, and then shut it down, without doing a reboot. However, it puzzles me that Firefox would think it is still there while it has been killed. And in any case, it shouldn't affect window resizing performance either 😉