1714113 - menu bar color does not follow WIndows system settings for active/inactive windows

Status: RESOLVED DUPLICATE of bug 1701266

(Core :: Widget: Win32, defect, P2)

Description

[mfinky]

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

Steps to reproduce:

open firefox v89

Actual results:

the menu bar window does not follow my Windows System configuration regarding active/inactive windows.
Which is: blue when active (aka focused, aka top window). Gray for inactive or not focused.

When I [Alt]-[Tab] through windows, I expect FIrefox to comply with my Windows settings, changing from gray to blue when ffox becomes the active window.
This was working ok for the previous firefox version on Windows 10 pro.

Expected results:

firefox window color and border properties should follow my Windows System configuration.
Manby other apps (notepad++, Excel , Word, etc) follow the menu bar color configuration.
The top menu bar for each application becomes blue when in focus (active) and becomes gray when the app is not the top focused window (inactive).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Christoph Kisfeld]

I can confirm this in 89 and 90.0b1 on Windows 10 x64

Comment 3

[Stephen A Pohl [:spohl]]

mozregression points to bug 1594132 as the culprit. Markus, do you know if this was an expected consequence of the change there?

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1594132

Comment 5

[Markus Stange [:mstange]]

(In reply to Stephen A Pohl [:spohl] from comment #3)

mozregression points to bug 1594132 as the culprit. Markus, do you know if this was an expected consequence of the change there?

I don't think it was an expected consequence of this change. The change was expected to have no effect on non-macOS.

However, I'm confused about what the bug means. I thought this gray toolbar color was part of the Proton theme; I would have expected the toolbar to stay gray on Windows both before and after bug 1594132, as long as the Proton theme was in use (controlled with a pref during the 88 / 89 time frame). But since you found a regression range, there must be something I'm missing.

Comment 6

[Stephen A Pohl [:spohl]]

Attachment: active-window-color-displayed.png

This screenshot shows the accent color properly displayed in the title and menu bar when the window is active.

Comment 7

[Stephen A Pohl [:spohl]]

Attachment: active-window-color-no-longer-displayed.png

This screenshot shows that the accent color is no longer displayed in the title and/or menu bar of the active window.

Comment 8

[Stephen A Pohl [:spohl]]

Attachment: last-good.png

Screenshot of last good version.

Comment 9

[Markus Stange [:mstange]]

Thanks Stephen! This clears up my confusion.

Okay, so this means that bug 1594132 "broke" window activeness coloring for the pre-Proton theme. But even in the "good" build, the Proton theme was already ignoring window activeness - you can see this by setting browser.proton.enabled to true in the "good" build.
So, while this was not an intentional change from bug 1594132, it was an intentional change from the Proton theme. As such, this bug is a duplicate of bug 1701266.