[Win7/8.1] Minimize, Maximize and Close buttons are no longer visible if Firefox Alpenglow theme is used with Webrender
Categories
(Firefox :: Theme, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox86 | --- | unaffected |
firefox87 | --- | unaffected |
firefox88 | --- | fixed |
People
(Reporter: root_pfad, Assigned: bugzilla)
References
(Regression)
Details
(Keywords: regression)
Attachments
(8 files)
+++ This bug was initially created as a clone of Bug #1677696 +++
Affected versions
- 88.0a1 (20210224100119)
Affected platforms
- Windows 8.1x64
Steps to reproduce
- Open Firefox and go to Customize mode.
- Set Alpenglow theme and observe the top buttons.
Expected result
- Buttons are displayed as expected.
Actual result
- The buttons are not displayed.
Notes
Tested with a new profile.
Comment 1•4 years ago
|
||
Hello! I can reproduce the above issue on Windows 7x64. This happenes with custom themes as well. Attaching the regression range:
1:53.95 INFO: Last good revision: b3fd546349160dfa293982cace9ba0f289d7788f
1:53.95 INFO: First bad revision: e5ee2e40acc0271d1e6032ab7e6058469cd7eef9
1:53.95 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b3fd546349160dfa293982cace9ba0f289d7788f&tochange=e5ee2e40acc0271d1e6032ab7e6058469cd7eef9
Moving to regressor's component. Feel free to change it if needed.
Harry, it seems that the patch from bug 1594132 caused the regression, can you please have a look? Thank you!
Assignee | ||
Comment 2•4 years ago
|
||
I can't reproduce on Windows 10. Does this bug reproduce when WebRender is not enabled? Could you please also send a screenshot of the broken behaviour?
Comment 3•4 years ago
|
||
Comment 4•4 years ago
|
||
Reproduced on Windows 8.1 with 88.0a1 per screenshot above. Can't reproduce with 86.0 and 87.0b2.
How to disable Webrender and retest? A web search tells me to toggle gfx.webrender.all and verify by checking the "compositing" field in about:support, but it was already set to "false" yet compositing status shows as Webrender, and toggling either way doesn't change it.
You can see the missing buttons in the top right.
As with Cletus I can't seem to disable webrender anymore.
Comment 6•4 years ago
|
||
(In reply to Cletus Van Damme from comment #4)
How to disable Webrender and retest? A web search tells me to toggle gfx.webrender.all and verify by checking the "compositing" field in about:support, but it was already set to "false" yet compositing status shows as Webrender, and toggling either way doesn't change it.
gfx.webrender.all can enable webrender if it is not enabled on your hardware by default.
gfx.webrender.force-disabled can disable webrender.
Comment 7•4 years ago
|
||
Ok. Not reproducible with Webrender disabled.
Comment 8•4 years ago
|
||
I can confirm as well that this is not reproducible with WebRender disabled on Windows7x64. Also, Windows 10x64 is not affected.
Assignee | ||
Comment 10•4 years ago
|
||
Bug 1594132 mostly changed macOS CSS styles. The only cross platform changes were to move a few background properties from :root :-moz-lwtheme
to #navigator-toolbox :-moz-lwtheme
. That bug also moves some background-image
properties from :root:-moz-lwtheme[lwtheme-image]
to :root[lwtheme-image] #navigator-toolbox
. Alpenglow is a [lwtheme-image]
theme, but it doesn't look like the theme in comment 5 is one, so I'm assuming it was the background-color change that broke this.
I spoke with mstange about this bug, and he pointed out that on Windows 7/8, WebRender erases the window-management buttons from its drawing for them to be visible. It does that by pushing a ClearRect
item. That happens after all the other drawing items are pushed, so my CSS change shouldn't have been able to erase the window-management buttons. That makes this a likely bug in WebRender.
I'm going to submit a Band-Aid fix that resets background-color on :root
only on Windows 7/8 and file a follow-up for the WebRender team.
Assignee | ||
Comment 11•4 years ago
|
||
I wrote a patch for this, but I don't have a Windows 7 or 8 machine to test it. Could someone please install one of these builds to see if the issue is fixed?
Assignee | ||
Comment 12•4 years ago
|
||
Ah, hold on, I think that build will break some different styling. I'll post a new build shortly. Sorry for the spam!
Assignee | ||
Comment 13•4 years ago
|
||
New builds:
Treeherder: https://treeherder.mozilla.org/jobs?repo=try&revision=986ee4f0a848ff3737b0d5b601abada897fdb619
Assignee | ||
Comment 14•4 years ago
|
||
While using -moz-os-version selectors in a shared CSS file isn't ideal, I think it's the best approach here. These selectors will hopefully be temporary, and will be removed when bug 1695280 is fixed. I considered a creating a ruleset like
@media (-moz-os-version: windows-win7),
(-moz-os-version: windows-win8) {
#navigator-toolbox:-moz-lwtheme {
background-color: unset;
}
:root:-moz-lwtheme {
background-color: var(--lwt-accent-color);
}
}
in browser/themes/windows/browser.css, but I think unsetting the background-color could become a headache if we need to make any other changes to the #navigator-toolbox background. We could also move these background rules to platform-specific stylesheets, but that way they're defined much later in the CSS despite being fairly foundational rules. It would also create more code to remove in bug 1695280.
Reporter | ||
Comment 15•4 years ago
|
||
Looks good! The buttons now appear correctly on Win 8.1 with WebRender enabled.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 16•4 years ago
|
||
I can confirm as well that the buttons are displayed as expected with the provided build from comment 13 on Windows7x64.
Assignee | ||
Comment 18•4 years ago
|
||
Could someone also please confirm if the alternate approach used in these builds fixes the issue as well?
Treeherder: https://treeherder.mozilla.org/jobs?repo=try&revision=537307bb906ea562e52dd6a34a261da4474af800
Comment 19•4 years ago
|
||
Assignee | ||
Comment 20•4 years ago
|
||
Thanks, Simon.
Comment 23•4 years ago
|
||
Comment 25•4 years ago
|
||
bugherder |
Reporter | ||
Comment 26•4 years ago
|
||
Confirmed fixed in Nightly build 20210304092248 on Win 8.1.
Comment 27•4 years ago
|
||
The buttons still get hidden when the application or window loses focus, and is quite distracting
- ctrl-shift-del: dialog has focus
- ctrl-n: new window
- ctrl-shift-k/j: console (see attachment)
- just click off into windows explorer or the desktop
Comment 28•4 years ago
|
||
Thank you, Simon!
Confirming the above behavior with 88.0a1 (20210310215846) on Windows 7x64 when the firefox window is not in focus and Firefox dark or light theme is used, I don't see this with random custom themes. Harry, should we reopen this bug or open another one? Thank you!
Description
•