[Firefox 115] UI Text Automatically Grays Out When Firefox Window Loses Focus (only for a split-second when using a keybinding)
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: skyskying93, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0
Steps to reproduce:
Behavior 1:
- Open a Firefox Window
- Make the FF window lose focus (by clicking another window/activating other windows)
Behavior 2:
- Open a Firefox window
- On i3wm, press a keybinding to activate a binding mode (https://i3wm.org/docs/userguide.html#binding_modes)
Actual results:
Behavior 1:
The UI text greys out.
Behavior 2:
The UI text flashes briefly when the keybinding is pressed.
Expected results:
The UI text doesn't change color when Firefox's window loses focus. Activating a binding mode shouldn't cause Firefox's UI text to flicker.
Please note that downgrading to Firefox 114 fixes the issue.
Follow up remark:
It is probable that Behavior 2 is a result of Behavior 1. When a keybinding is pressed to activate a binding mode, the widow focus will briefly switch to i3bar. The "flash" in the UI text is the result of Firefox losing focus briefly before regaining focus again.
Comment 3•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 4•1 year ago
|
||
The color change seems correct, but I don't know why the window flashes between deactivated and activated in the first place. Seems like a bug in the WM or our widget code.
(In reply to Dão Gottwald [:dao] from comment #4)
The color change seems correct, but I don't know why the window flashes between deactivated and activated in the first place. Seems like a bug in the WM or our widget code.
It's definitely not a bug in the WM. FF 114 running with the same WM doesn't exhibit this behavior.
Comment 6•1 year ago
|
||
(In reply to Anthony from comment #5)
(In reply to Dão Gottwald [:dao] from comment #4)
The color change seems correct, but I don't know why the window flashes between deactivated and activated in the first place. Seems like a bug in the WM or our widget code.
It's definitely not a bug in the WM. FF 114 running with the same WM doesn't exhibit this behavior.
A regression range might be helpful then. See https://mozilla.github.io/mozregression/ for more information. Are you able to help with this? I suspect this bug could be tricky to reproduce by our QA folks, so your help would be appreciated.
Previously the tab and menubar text color did not use the titlebar text color with CSD disabled (browser.tabs.inTitlebar = 0
). Now it does, causing the window active state to affect the tab text color.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4e43ca74c9198f6c01d64095bd77e8f2441eed95&tochange=752dc76b26eb54e7dfa875c749e91526496688b6
Regressed by Bug 1831841.
Comment 9•1 year ago
|
||
That change was intentional, but let's keep this bug focused on the flashing behavior when pressing a keybinding.
Comment 10•1 year ago
|
||
(In reply to Anthony from comment #5)
It's definitely not a bug in the WM. FF 114 running with the same WM doesn't exhibit this behavior.
When testing versions 114 and earlier, you will need to check for flashing in the titlebar rather than the tabs. Are you sure the titlebar doesn't flash with other apps?
Comment 11•1 year ago
|
||
:dao do you know what the priority/severity on this is now that we have a regressor?
Comment 12•1 year ago
|
||
Set release status flags based on info from the regressing bug 1831841
Updated•1 year ago
|
Comment 14•1 year ago
|
||
Does nightly exhibit the same behavior? Bug 1838460 should have restored the previous behavior.
Other than that, reacting to window focus changes, while unfortunate in this case because the focus change is temporary, seems intended?
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 15•9 months ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE
.
For more information, please visit BugBot documentation.
Updated•9 months ago
|
Updated•9 months ago
|
Description
•