macOS Sequoia "Domain name cannot be nil or empty" #164
Comments
|
I trimmed the function right down as far as I can and I still have the same issue. Obviously this variant isn't very functional at all but it still gives me the same issue with the dialog runModal failing still. nfdresult_t NFD_OpenDialogN_With_Impl(nfdversion_t version,
nfdnchar_t** outPath,
const nfdopendialognargs_t* args) {
NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
nfdresult_t result = NFD_CANCEL;
NSOpenPanel* dialog = [NSOpenPanel openPanel];
if ([dialog runModal] == NSModalResponseOK) {
result = NFD_OKAY;
}
return result;
} |
|
This is the output from ChatGPT when trying to diagnose the situation -- seems that Sequoia indeed has changed the game; Thanks for confirming — since this happens during a file picker (like NSOpenPanel or NSSavePanel), the most likely cause is that something (either your app or a system helper/view service) is trying to modify NSUserDefaults with an invalid domain — specifically, an empty or nil string. Here’s how to approach debugging and resolving this: 🚨 What’s likely happening macOS Sequoia uses sandboxed helper processes (via ViewBridge) to show open/save panels. One of these helpers (either yours or a system one) is trying to set user defaults using setObject:forKey:inDomain: with an invalid domain. This used to silently fail or be ignored in previous macOS versions but now throws a hard exception in Sequoia. 🔍 Possible causes You (or a library you use) may be customizing the NSOpenPanel or NSSavePanel and accidentally triggering this. You're installing/accessing something in the panel delegate that manipulates NSUserDefaults using an invalid domain. You use a third-party framework (e.g. for theming, file handling, or sandboxing) that hooks into file panels and does this. |
|
Thanks for the report. This looks somewhat bad if it's making NFDe unusable for all users on macOS Sequoia. If you have access to a machine running Sequoia, do you mind checking if the example programs function correctly on it? (You can do a quick test by downloading the prebuilt binaries from the CI at https://github.com/btzy/nativefiledialog-extended/actions/runs/13874562190. There are three macOS build artefacts there, but I think just testing the two of them that are labelled as "Static" should be sufficient.) This should help us quickly figure out if this is an NFD problem or something else. |
|
Can confirm that I've tested the open_cpp_cpp test (and test_sdl2) and it works on Sequoia; as such the problem/issue lays elsewhere ( something clobbering the NSUserDefaults domain I suppose ). I'll report back what I can find as I suspect this issue may afflict some others. |
|
Reporting back here in case anyone else suffers this misfortune. Be sure to populate/add the MACOSX_BUNDLE_GUI_IDENTIFIER attribute for the target properties, as this is the true issue. |
Hopefully not wasting people's time here.
I've noticed people using my program on macOS Sequoia, either Intel or ARM are unable now to use the Save-As / Open / Folder-select NFD's and best I can see there's an error presented in the "Console".
The program itself reports "picker_folder: selection cancelled".
No issues with the code in prior macOS releases (and this is built on Catalina Intel)
Function that is called is this...
The text was updated successfully, but these errors were encountered: