Buttons, Selects, right-click menu, display transparently
Categories
(Core :: Widget: Cocoa, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox77 | --- | fixed |
People
(Reporter: morgan, Assigned: spohl)
Details
Attachments
(6 files)
test_ffoxnightly.png
Expected:
(1) Run Firefox Nightly, or Firefox and load the following test case: data:text/html,<body style="background:yellow;"><button>Test</button></body>
(2) Note the button shows black text on a white background, with a yellow body background
Actual:
(1) Run Nightly Debug and load the following test case: data:text/html,<body style="background:yellow;"><button>Test</button></body>
(2) Note the button shows white text on a transparent background with a yellow body background.
The same defect appears in local nightly builds for right-click menus and "Do you want to close all tabs?" popups. Screenshots attached below.
EDIT:
My builds are:
|
Reporter | |
Comment 1•5 years ago
|
||
|
|
Reporter | |
Comment 2•5 years ago
|
||
|
|
Reporter | |
Comment 3•5 years ago
|
||
CC'ing @mstange, might be a web render bug ?
|
||
Comment 4•5 years ago
|
||
mstange suspected (in IRC) that this might be due to a SDK difference. (Seems likely it's some difference between the build envs on our infra builders vs. the build env on local developers' machines).
|
Assignee | |
Comment 5•5 years ago
|
||
Can you tell us what SDK you're using to build Firefox? Does it reproduce with the 10.11 SDK?
|
|
Reporter | |
Comment 6•5 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #5)
Can you tell us what SDK you're using to build Firefox? Does it reproduce with the 10.11 SDK?
How do I check my SDK?
|
|
Assignee | |
Comment 7•5 years ago
|
||
(In reply to Morgan Reschenberg [:morgan] from comment #6)
(In reply to Stephen A Pohl [:spohl] from comment #5)
Can you tell us what SDK you're using to build Firefox? Does it reproduce with the 10.11 SDK?
How do I check my SDK?
If you don't have --with-macos-sdk specified in your .mozconfig file you are building with the SDK that matches your version of macOS. So if you're on 10.14, you're building with the 10.14 SDK by default. Our build system uses 10.11 and there are significant differences between SDKs that could explain what you're experiencing here.
|
|
Reporter | |
Comment 8•5 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #7)
(In reply to Morgan Reschenberg [:morgan] from comment #6)
(In reply to Stephen A Pohl [:spohl] from comment #5)
Can you tell us what SDK you're using to build Firefox? Does it reproduce with the 10.11 SDK?
How do I check my SDK?
If you don't have
--with-macos-sdkspecified in your .mozconfig file you are building with the SDK that matches your version of macOS. So if you're on 10.14, you're building with the 10.14 SDK by default. Our build system uses 10.11 and there are significant differences between SDKs that could explain what you're experiencing here.
I'm currently building with 10.14 (no mozconfig sdk specified). I'll try a 10.11 build and let you know if that changes things :)
|
|
Reporter | |
Comment 9•5 years ago
|
||
Re-built and ran above test with SDK 10.11; buttons render as they should, and the bug is not present.
|
|
Assignee | |
Comment 10•5 years ago
|
||
Thanks for confirming. Marking this as blocking bug 1475652.
|
||
Comment 11•5 years ago
|
||
I had written a comment for this bug last week but it looks like I forgot to submit it. Here it is anyway:
Yeah, behavioral differences between Nightly builds and local builds are usually due to SDK differences, especially if they happen in system libraries. Which is the case here: The button backgrounds are painted by a system library that Firefox calls for buttons that it wants to look native. Background: In new releases of macOS, Apple often wants to make changes to how certain OS APIs work, but then they find incompatibilities with existing apps. (Unreadable button text in web pages in Firefox would be such an incompatibility.) Then they put the change inside an if that checks whether the calling app has been built with the new OS version's SDK. This means that existing apps get the old behavior. And it's up to app developers to find a way to deal with the new behavior once they switch to the new SDK.
Our builders currently use the 10.11 SDK when compiling Firefox Nightly builds. (Bug 1475652 tracks updating this.) And local builds use the SDK that Xcode comes with by default, unless you override the SDK in your mozconfig with ac_add_options --with-macos-sdk=/path/to/SDK.
I see transparent buttons, too, if I build with the 10.14 SDK.
We'll need to find a solution before we switch to the 10.14 SDK. I can see two possible solutions: 1. Finding a way to opt our button rendering into the non-transparent style, or 2. Switching away from native button rendering to manual drawing, i.e. bug 1535761.
|
||
Comment 12•5 years ago
|
||
Apple allows you to set NSRequiresAquaSystemAppearance to true in Info.plist which allows you to opt-out from the dark mode stuff, which might also include transparent buttons. Though that key may be removed in future macOS versions, so it would be better to find a "proper" fix.
You can also opt-out from dark mode appearance/colors by setting the appearance property of different elements to NSAppearance(named: .aqua), this won't be removed in future macOS versions though, since there are some genuine use-cases for this. Not sure this gets rid of the transparent appearance reported in this bug though.
|
|
||
Comment 13•5 years ago
|
||
We might also be able to find a different way to get at the "actual" Aqua appearance in https://searchfox.org/mozilla-central/source/widget/cocoa/nsNativeThemeCocoa.mm#818-822.
|
||
Comment 14•5 years ago
|
||
|
||
Comment 15•5 years ago
|
||
This seems to be the last major bug preventing moving to the 10.14 SDK (which is needed for other things).
Is anyone working on it?
|
|
Assignee | |
Comment 16•5 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #15)
This seems to be the last major bug preventing moving to the 10.14 SDK (which is needed for other things).
Is anyone working on it?
I have explored this a bit as part of bug 1593390. Switching to the 10.14 SDK also causes us to run into issues related to dark mode that have not been filed yet (as far as I can tell), but are mentioned in bug 1593390 comment 4 and bug 1593390 comment 5. Unfortunately, I don't have any meaningful progress to report.
|
|
Reporter | |
Comment 17•5 years ago
|
||
Bumping this, as it seems like <input>s are also an issue
|
|
Reporter | |
Comment 18•5 years ago
|
||
|
|
Assignee | |
Comment 19•5 years ago
|
||
Once bug 1623684 lands, this bug won't block the switch to a new SDK anymore. However, it will block bug 1623686 where we intend to remove the Info.plist key that forces the aqua appearance on.
|
|
Assignee | |
Comment 20•5 years ago
|
||
It looks like the fix in bug 1623684 broke with the macOS 10.15.4 update. Markus, are you still running an earlier version of 10.15? And would you be able to confirm that the fix in bug 1623684 still works there?
I have verified that builds with the 10.14 SDK, an early 10.15 SDK as well as the latest 10.15.4 SDK all show buttons with a transparent background on macOS 10.15.4. Only builds with the 10.11 SDK still display as expected.
|
|
Assignee | |
Comment 21•5 years ago
|
||
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 22•5 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #20)
It looks like the fix in bug 1623684 broke with the macOS 10.15.4 update. Markus, are you still running an earlier version of 10.15? And would you be able to confirm that the fix in bug 1623684 still works there?
I have verified that builds with the 10.14 SDK, an early 10.15 SDK as well as the latest 10.15.4 SDK all show buttons with a transparent background on macOS 10.15.4. Only builds with the 10.11 SDK still display as expected.
It turns out that unlike what I mentioned in the review for bug 1623684, we actually have to force Aqua appearance on for content processes as well. And we may as well turn this on for the crash reporter and the updater too at this point. I can't say why this didn't show up in my local testing. If I had to guess, this change may have still been applied locally but not committed.
One interesting observation that I made while looking into this is that if we set kCGImageAlphaNoneSkipFirst instead of kCGImageAlphaPremultipliedFirst as bitmapInfo in our call to CGBitmapContextCreate[1], we render buttons in dark mode. It looks like the buttons have vibrancy and display some of the background color. The white labels are then readable on top of the darker button background when macOS is in dark mode. However, I haven't been able to find the proper combination of clipping the CGRect, creating opaque vs. transparent CGContext's using the appropriate CGImageAlphaInfo types etc. to only show the button with the dark background. It either shows a much larger rectangle with the opaque, black background (will attach a screenshot shortly), or I'm clipping too much for focus rects to still appear correctly. Markus, maybe you have some thoughts here?
|
|
Assignee | |
Comment 23•5 years ago
|
||
|
|
Assignee | |
Comment 24•5 years ago
|
||
|
||
Comment 25•5 years ago
|
||
|
||
Comment 26•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
|
||
Comment 27•4 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #22)
One interesting observation that I made while looking into this is that if we set
kCGImageAlphaNoneSkipFirstinstead ofkCGImageAlphaPremultipliedFirstasbitmapInfoin our call toCGBitmapContextCreate[1], we render buttons in dark mode. It looks like the buttons have vibrancy and display some of the background color. The white labels are then readable on top of the darker button background when macOS is in dark mode. However, I haven't been able to find the proper combination of clipping theCGRect, creating opaque vs. transparentCGContext's using the appropriateCGImageAlphaInfotypes etc. to only show the button with the dark background. It either shows a much larger rectangle with the opaque, black background (will attach a screenshot shortly), or I'm clipping too much for focus rects to still appear correctly. Markus, maybe you have some thoughts here?
kCGImageAlphaNoneSkipFirst just means that there is no transparency, so the CGContext starts out with opaque black. So the black comes from CGContext initialization, not from the button drawing. And drawing transparent widgets on top of a black background ends up looking like a dark mode widget.
Description
•