User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Installed Firefox Developer update 72.0b1 on December 3rd

Actual results:

The top portion of the browser where the tabs are and the main title of the window is transparent when it should be the color of the theme chosen. Only active tabs get the color picked.

Expected results:

There should be no transparency in the title bar or the inactive tabs.

Can confirm similar issues in Beta and Nightly. Latest versions.

Upgraded Firefox Developer to 71.0b2 and Firefox Color is still broken. Firefox Color needs to be updated; the last update was 3 months ago.

Sorry, that should say 72.0b2

Broken in 73.0a1 as well.

Had to throw in two CCs of people who dealt with the v.70 issue as the triage consolidator attached to this bug report hasn't been active in over two months.

hi, sorry i won't be able to help much here since i don't have a system available where i could try to reproduce (windows 7 with transparency on). it would help if you could use the tool from https://mozilla.github.io/mozregression/ and point it towards your existing profile in order to narrow down which exact change in firefox 72 has caused this and/or file an issue in the github section where firefox color is developed: https://github.com/mozilla/FirefoxColor/issues

Regression check comes and goes between dates. I had to test it to see how viable it is. When using the the tool it goes back and forth so it isn't reliable. Which makes me suspect it's Firefox Color needing updating, because this behavior is coming up in a freshly spun install of Windows on a VM.

(In reply to Alex from comment #7)

Regression check comes and goes between dates. I had to test it to see how viable it is. When using the the tool it goes back and forth so it isn't reliable.

that's the way the tool works - it's going back and forth constantly narrowing down the regression range based on your input until you (hopefully) end up on a single bug which introduced the problem. it's a great resource to pin down regressions!
please also refer to the howto video on the homepage on how to use it...

Going by profile didn't work. Going by the video did. Profiles had nothing to do with the problem because even a brand new profile had the same problem.

Anyway, this is what comes up testing Nightly x64:

Bug 1592739 - Stop using the vibrant region as the transparent region. r=mattwoodrow

This code was assuming that the only non-opaque parts of compositor rendering would be the
parts of the window that had vibrancy. But now that the default window background is transparent,
we can have non-vibrant parts where we render into transparency. Dialog windows such as sheet
windows are an example of this.
So instead of using the non-vibrant region of the window as its opaque region, we now use
the region that is covered by opaque Gecko layers. This region is a lot more conservative:
For example, the main browser chrome is now entirely transparent, because the chrome's opaque
parts share a layer with its transparent parts.
As a result, this change slightly affects the CALayer partitioning in the main browser window:
The entire browser chrome is now transparent, not just the tab bar.
The web content area is still opaque.

I think this will be fine. The thing I'm most concerned about is that scrolling inside web
content might cause invalidations of pixels from the chrome, because then we'd recomposite
the CALayers that cover the vibrant tab bar. This doesn't seem to happen most of the time
though, from what I can tell.

Differential Revision: https://phabricator.services.mozilla.com/D51466

pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e96c1ca93d2597b77def89d16f594c3e3b98787b&tochange=5275ea4d5a1aec6e1e66e051456c4239fe91df11

I'm not sure why an issue in macOS is popping up on the Windows side of things, or why that person thinks this behavior is fine. What's the point of Firefox Color if it's supposed to be a easier way to setup a custom color theme without having to find a color theme that's close to what you want or make your own and package it?

This is very frustrating and I'm surprised I'm the only one complaining about this. There have to be more people on Beta, Dev, and Nightly and use Firefox Color other than myself.

Is this basically bug 1594771? If so it is not that this stopped working, but that the conditions under which it works are different, see there.

That is why I presumed, Carlos. However, out of curiosity I spun up a Windows 10 VM (Thank goodness for NVME drives) and installed Nightly (73.0a1 (2019-12-15) (64-bit)) and Beta (72.0b7 (64-bit)) and it works fine with Firefox color.

I then considered it might be because I disabled hardware acceleration, enabling it did not fix the problem.
I then presumed it was the lack of GPU pass through on my VM that made it usable, it being Firefox color, except that also isn't the case.

I have made new profiles.
Uninstalled Firefox and cleared my system of its traces and re-imported the profile.
I've removed Firefox in its entirety and only brought in bookmarks, only to find myself not seeing Firefox color behave as it should.

Markus, does anything here ring a bell?

Sorry, Emilio. I accidentally called you Carlos. If it's any help, I'm on Windows 7 but I don't think builds differ much between OSs for Mozilla? I'm not completely sure. I don't have a W7 install ISO to test it out in a VM.

I was able to reproduce this issue on Aurora Dev Edition Version 72.0b1 Build ID 20191202142314 on Windows 7.

Thank you Marcela. I'm still trying to hunt down my ISO files but your confirmation helps. It hadn't occurred to me to use my laptops as a testing ground because my bug report was merely about my main computer. I was also able to confirm this being an issue on two other laptops that run Windows natively and a MBP which has a W7 VM on it.

I suspect this may crop up as an issue in future W10 versions because they've been playing around with "Acrylic" which is a better implemented and fancier "Aero" may pop up as a problem in the future with Firefox. Right now on Windows stable channels, I do not believe W10 implements the title bar area or any such area in an "Acrylic"/"Aero" format. However, this may change in the future simply due to how styles are cyclical every few years.

On Windows 7, when setting a background color on the root element, we now (as of bug 1592739) also need to set -moz-appearance: none, otherwise the background color won't apply. I'm not sure yet what the best place to do that is.

I'm planning to have bug 1592739 backed out from 72 so that there's more time to find a fix.

https://hg.mozilla.org/releases/mozilla-beta/rev/e3a91b611720

This appears to have been fixed.

The priority flag is not set for this bug.
:mattwoodrow, could you have a look please?

For more information, please visit auto_nag documentation.

Regression back as of 73.0b1

74.0a1/Nightly also affected.

The priority flag is not set for this bug.
:mattwoodrow, could you have a look please?

For more information, please visit auto_nag documentation.

Fixed for 73.0b5 by backout:
https://hg.mozilla.org/releases/mozilla-beta/rev/ff911052beb1

Now fixed in Developer 73.0b6. I've been pushed a few updates the last few days and didn't notice until just now it had been fixed.

Matt, What is the status of this bug wrt to 74? Should we backout bug 1592739 when we get into beta 74 as we did with beta 73?

Markus, can we back out bug 1592739 now that we are in beta?

I chatted with Markus yesterday and we're going to do that today.

Regressor backed out for 74 and 75 now too:
https://hg.mozilla.org/releases/mozilla-beta/rev/fee92a1f6d6ec6ea10f6c431439dfaea26e54baa
https://hg.mozilla.org/integration/autoland/rev/ecc5c853bb770cc3f9acc90d9ed9febe086671a0