[Linux] Menubar and tab-title text changes to inactive/active color when Firefox window loses/gains focus, potentially after substantial jank/delay
Categories
(Firefox :: Theme, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox122 | --- | fixed |
People
(Reporter: dholbert, Assigned: emilio)
References
Details
Attachments
(3 files)
As of bug 1869299 (pushlog https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=34533b3add99fe26cbd60a7fd8d0c60966e5fd32&tochange=89da90df398f5aee595e14748b0241ede2a9fd4d ), the Firefox tab-title text and menu bar text changes to be an inactive-looking gray color when you move Firefox windows to the background; and then the text changes to be dark again when the window moves to the foreground.
In my main browsing profile, this repaint is delayed by about 1 second when I switch between Firefox windows. The jank itself seems to be bug 1849393 -- a performance-profile shows me spending ~736ms in SessionWriter.sys.mjs write
when I switch windows -- but previously that delay wasn't as visually-noticeable. Now that we're queuing up a more-noticeable repaint on window-switch, it makes this jank a bit more of a visual problem.
(Previously, we just changed the tint of some background colors when foregrounding/backgrounding a window, but the window didn't look quite as obviously "wrong" during a period of jank. Now that we have grayed-out text, it looks quite wrong during the jank period when the window is clearly in the foreground and yet using inactive text.)
Here's a profile (URLs redacted) in my main browsing profile showing a window-switch operation:
https://share.firefox.dev/48fwgpt
Not quite sure how best to track this; this is sort of a dupe/manifestation of bug 1849393, but the visibility of the issue has been increased due to this theme change, to my eye at least.
Reporter | ||
Comment 2•1 year ago
|
||
Here's a screencast showing how this looks, with me alt-tabbing back and forth between my main Firefox window (many tabs open, tabstrip not shown here for privacy) and a new window. You can see there's a ~1s delay between the new window being foregrounded and the text losing its "inactive" grayed-out look.
Reporter | ||
Comment 3•1 year ago
|
||
Here's another profile that I took while doing a few additional alt-tab operations like the ones shown in the screencast:
https://share.firefox.dev/3v1U3eg
This shows that this isn't just bug 1849393; we're also doing some extremely-long (300-400ms) restyle operations. Possibly because my main browsing window has several hundred tabs open and they all get their tab title-text restyled when the window gets foregrounded/backgrounded. I'm not sure if that part may have gotten more expensive as a result of bug 1849393 (due to the text color change), or if it's just more noticeable now.
Reporter | ||
Comment 4•1 year ago
|
||
Hmm, if my browser-toolbox's view of my tabstrip is to be trusted, I may have ~3900 tabs open in my main Firefox Window. So that may make my experience a bit edge-casey and might partially explain why the tabstrip-restyle is so expensive.
Assignee | ||
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Gonna move this to Session Restore. It really shouldn't block the next paint when switching windows.
Assignee | ||
Comment 6•1 year ago
|
||
Dao, I have a theming side fix for this slow restyle regression, but Phabricator is stuck: https://phabricator.services.mozilla.com/D196543
I'll file a separate one for the session restore.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 7•1 year ago
|
||
This avoids big restyles when users have a massive number of tabs. A
color change inherits, so we need to propagate the color change to the
whole subtree, which with a lot of tabs can be huge (66k elements in the
profile in the bug).
Instead, don't change the text color on inactive windows, and fade the
titlebar entirely using opacity, which is a one-element change.
Assignee | ||
Comment 8•1 year ago
|
||
Reporter | ||
Comment 9•1 year ago
|
||
(In reply to Dão Gottwald [:dao] from comment #5)
Gonna move this to Session Restore. It really shouldn't block the next paint when switching windows.
For reference, Emilio spun this part off as bug 1870245.
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
Comment 12•1 year ago
|
||
bugherder |
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 13•1 year ago
|
||
bugherder |
Description
•