Closed Bug 1578917 Opened 5 years ago Closed 4 years ago

Buttons, Selects, right-click menu, display transparently

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla77
Tracking Flags:
Tracking Status
firefox77 --- fixed

People

(Reporter: morgan, Assigned: spohl)

Details

Attachments

(6 files)

test_ffoxnightly.png
4.32 KB, image/png
Details
test_debugnightly.png
4.12 KB, image/png
Details
inputs_text.png
490.53 KB, image/png
Details
Bug 1578917: Force macOS Aqua appearance on for content processes, crash reporter and updater. r=mstange
47 bytes, text/x-phabricator-request
Details | Review
Button, dropdown, checkbox, radio controls and progress bar
8.71 KB, image/png
Details
File picker buttons, reset button, submit button and color picker
9.06 KB, image/png
Details

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:

Diff: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=174361d152923aea2b24226a57cde3099509ed6a&tochange0a0112c2cad4

Attached image test_ffoxnightly.png —
Attached image test_debugnightly.png —

CC'ing @mstange, might be a web render bug ?

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).

Can you tell us what SDK you're using to build Firefox? Does it reproduce with the 10.11 SDK?

Flags: needinfo?(mreschenberg)
Priority: -- → P3

(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?

Flags: needinfo?(mreschenberg)

(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.

Flags: needinfo?(mreschenberg)

(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-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.

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 :)

Flags: needinfo?(mreschenberg)

Re-built and ran above test with SDK 10.11; buttons render as they should, and the bug is not present.

Thanks for confirming. Marking this as blocking bug 1475652.

Blocks: mojave-sdk

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.

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.

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.

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?

(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.

Bumping this, as it seems like <input>s are also an issue

Attached image inputs_text.png —

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.

Blocks: 1623686
No longer blocks: mojave-sdk

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.

Flags: needinfo?(mstange)
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED

(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?

Flags: needinfo?(mstange)
Pushed by spohl@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0d2e6a6fc291
Force macOS Aqua appearance on for content processes, crash reporter and updater. r=mstange

https://hg.mozilla.org/mozilla-central/rev/0d2e6a6fc291

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox77: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
QA Whiteboard: [qa-77b-p2]

(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 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?

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.

No longer blocks: 1623686
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: