Closed Bug 1494022 Opened 6 years ago Closed 5 years ago

Fully black window when compiling and running Firefox with the 10.14 OSX SDK

Categories

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

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox64 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- fixed

People

(Reporter: johannh, Assigned: mstange)

References

(
URL
)

Details

I just upgraded to Mojave and after fixing the other build-related failures and compiling successfully, all Firefox windows are pitch black on startup and I can't escape that state. Miko had the same issue and figured out that downgrading to the 10.13 SDK fixes it. Standard8 pointed me to this issue, which might be related: https://support.mozilla.org/en-US/questions/1234707
Looks like we need to accelerate the work happening in bug 1491442. I'd expect that to fix this problem. Building with the 10.14 SDK force-enables CoreAnimation for all windows. I don't know why that would break our current present path.
Is this a dupe of bug 1493330?
status-firefox64: --- → affected
It happens to me. I have tried the workarounds from bug 1493330, and it doesn't work. Is there any recommend way to quick skip this issue to let me continue doing on my MacOS development? Or, I have to downgrade it back to 10.13?
(In reply to Daosheng Mu[:daoshengmu] from comment #3) > It happens to me. I have tried the workarounds from bug 1493330, and it > doesn't work. Is there any recommend way to quick skip this issue to let me > continue doing on my MacOS development? Or, I have to downgrade it back to > 10.13? I don't know if you worked around it already but I worked around it with downgrading the macOS SDK. This repository includes older macOS SDKs: https://github.com/phracker/MacOSX-SDKs . You can pull the repository and add a symbolic link of 10.13 SDK path to `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs`. Then update the `MinimumSDKVersion` in `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist`. This should fix the black window problem for now.
(In reply to Chris Peterson [:cpeterson] from comment #2) > Is this a dupe of bug 1493330? No, bug 1493330 refers to a black window showing in the shipping version of Firefox. This bug here refers to black windows when compiling with the 10.14 SDK. (In reply to Nazım Can Altınova [:canaltinova] from comment #4) > (In reply to Daosheng Mu[:daoshengmu] from comment #3) > > It happens to me. I have tried the workarounds from bug 1493330, and it > > doesn't work. Is there any recommend way to quick skip this issue to let me > > continue doing on my MacOS development? Or, I have to downgrade it back to > > 10.13? > > I don't know if you worked around it already but I worked around it with > downgrading the macOS SDK. This repository includes older macOS SDKs: > https://github.com/phracker/MacOSX-SDKs . You can pull the repository and > add a symbolic link of 10.13 SDK path to > `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/ > Developer/SDKs`. Then update the `MinimumSDKVersion` in > `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info. > plist`. This should fix the black window problem for now. FYI, Firefox is currently being built using the 10.11 SDK.
(In reply to Nazım Can Altınova [:canaltinova] from comment #4) > I don't know if you worked around it already but I worked around it with > downgrading the macOS SDK. This repository includes older macOS SDKs: > https://github.com/phracker/MacOSX-SDKs . You can pull the repository and > add a symbolic link of 10.13 SDK path to > `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/ > Developer/SDKs`. Then update the `MinimumSDKVersion` in > `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info. > plist`. This should fix the black window problem for now. So I did put SDK 10.11 and 10.13 into the Developer/SDKs directory. And the Info.plist shows 10.11 as the minimum version. But I still get the black window. Do I need to specify the lower SDK version numbers also somehow in the Firefox build?
Not sure if it's necessary, since I haven't hit this yet, but in the past I used the following in my mozconfig: > ac_add_options --with-macos-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
(In reply to Nils Ohlmeier [:drno] from comment #6) > (In reply to Nazım Can Altınova [:canaltinova] from comment #4) > > I don't know if you worked around it already but I worked around it with > > downgrading the macOS SDK. This repository includes older macOS SDKs: > > https://github.com/phracker/MacOSX-SDKs . You can pull the repository and > > add a symbolic link of 10.13 SDK path to > > `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/ > > Developer/SDKs`. Then update the `MinimumSDKVersion` in > > `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info. > > plist`. This should fix the black window problem for now. > > So I did put SDK 10.11 and 10.13 into the Developer/SDKs directory. And the > Info.plist shows 10.11 as the minimum version. But I still get the black > window. Do I need to specify the lower SDK version numbers also somehow in > the Firefox build? Oops, sorry, I missed to mention about the mozconfig part. As Matthew said, you also need to add `--with-macos-sdk=<sdk-path>` option to your mozconfig like in the comment 7.
Priority: -- → P3
It would probably be good to fail to build with 10.14 and point at this bug to help people figure out what's going on sooner.
Worthy of a note, you can't compile with brew's clang (or llvm.org one) with the 10.14 SDK either, various failures occur. Must use Xcode's clang MacOS10.13.sdk works well, I'll put it up on a server next so it's easy for people to retrieve.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #9) > It would probably be good to fail to build with 10.14 and point at this bug > to help people figure out what's going on sooner. Filed bug 1500504.
I'm pretty sure the issue is the same one as this: https://github.com/tomaka/winit/pull/685 Copy and pasting my description: On Mojave, views automatically become layer-backed shortly after being added to a window. Changing the layer-backedness of a view breaks the association between the view and its associated OpenGL context. To work around this, on Mojave we explicitly make the view layer-backed up front so that AppKit doesn't do it itself and break the association with its context. Dolphin has an alternative fix: https://github.com/dolphin-emu/dolphin/pull/7039#issuecomment-425700807
(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #7) > Not sure if it's necessary, since I haven't hit this yet, but in the past I > used the following in my mozconfig: > > ac_add_options --with-macos-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk Need to ./mach build after update sdk path?
Yeah, probably after a `./mach clobber`
Warning: every time Apple releases an update of the command line tools, like today, it apparently blows away the SDK directory and you have to redeploy the old SDK(s).
(In reply to Nils Ohlmeier [:drno] from comment #16) > Warning: every time Apple releases an update of the command line tools, like > today, it apparently blows away the SDK directory and you have to redeploy > the old SDK(s). There is no requirement to keep the SDK directory inside the Xcode.app bundle. You can keep it under your ~/Documents directory and it will not be touched by an update to the command line tools (or Xcode, for that matter).
After following the directions above using OS X SDK v10.13, clobbering, clearing the ccache, and sccache, I was still getting a black screen. During the build I did observe warnings referencing the headers in the 10.13 SDK so I assume the changes were in fact picked up. I disabled icecc, recompiled and now the black screen is gone.

(In reply to Markus Stange [:mstange] from comment #1)

Building with the 10.14 SDK force-enables CoreAnimation for all windows. I
don't know why that would break our current present path.

From https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes/appkit_release_notes_for_macos_10_14#3014921 :
"Windows in apps linked against the macOS 10.14 SDK are displayed using Core Animation when the app is running in macOS 10.14."

Stephen - who should own this bug?

Flags: needinfo?(spohl.mozilla.bugs)

:mstange is working on CoreAnimation. This bug only affects developers, hence the lower priority compared to other pressing issues.

Flags: needinfo?(spohl.mozilla.bugs)

Assigning to myself, because I hope that bug 1491442 will help with this, but 10.14 is not the primary focus of that work.

Assignee: nobody → mstange
Status: NEW → ASSIGNED
Depends on: 1491442

thanks for taking this :mstange, in Bug 1549052, :kats suspects that our ability to run wheel related tests will require a newer OSX SDK- I see in bug 1491442 there is recent history- hopefully that can land- maybe I could test with those patches to see if wheel events work?

Depends on: 1574538

This should be completely fixed on mozilla-central now. No black windows, and no odd squishy windows or double window buttons.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox68: --- → wontfix
status-firefox69: --- → wontfix
status-firefox70: --- → fixed
status-firefox-esr60: --- → wontfix
status-firefox-esr68: --- → wontfix
OS: Unspecified → macOS
Hardware: Unspecified → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #24)

thanks for taking this :mstange, in Bug 1549052, :kats suspects that our ability to run wheel related tests will require a newer OSX SDK- I see in bug 1491442 there is recent history- hopefully that can land- maybe I could test with those patches to see if wheel events work?

The work in those bugs is completely orthogonal to wheel events but I think kats landed a solution for wheel events anyway.

Well, sounds like windows are now not black but dark gray, see bug 1576113. I'm going to try to reproduce that tonight.

You need to log in before you can comment on or make changes to this bug.