macOS: where the "Ask every time" save dialog appears #596

Activity

1. KnifeLemon

   added

   bugSomething isn't workingSomething isn't working

   macosRun the macOS packages and tests in CI for this pull requestRun the macOS packages and tests in CI for this pull request

   on Oct 26, 2026
2. KnifeLemon commented on Nov 4, 2026

   

   KnifeLemon

   on Nov 4, 2026

   OwnerAuthor

   More actions

   Update for 2.3.0: Copy to folder and Move to folder with Save to: Ask every time go through the same dialogs (WindowService.AskSaveLocationAsync, same 1×1 host window), so they belong in the Mac check too:

   • one file → save dialog (no overwrite prompt for copies), several → folder dialog;
   • a file dragged from a browser still asks for these two (other presets save to Downloads);
   • when the source's folder is gone, the dialog starts in Downloads.

   Still untested on a Mac.
3. KnifeLemon commented on Nov 5, 2026

   

   KnifeLemon

   on Nov 5, 2026

   OwnerAuthor

   More actions

   @AzrielTheHellrazor since you offered to test on macOS: could you try this one when you have a moment? Nobody has run it on a Mac yet.

   Setup: a preset with Save to: Ask every time.

   Please try:

   1. Drop one file on the donut from Finder (save dialog, starting in the file's folder).
   2. Drop several files (folder dialog, asked once).
   3. Both again with the main window open and with it closed.
   4. Cancel the dialog: nothing should start.
   5. Copy to folder and Move to folder with the same setting.

   Please tell us: where the dialog shows up (a sheet, near the cursor, behind other apps, on another Space), and a screenshot if it's in an odd place.
4. AzrielTheHellrazor commented on Nov 6, 2026

   

   AzrielTheHellrazor

   on Nov 6, 2026

   Last edited by AzrielTheHellrazor

   Collaborator

   More actions

   Hi @KnifeLemon,

   I tested the "Ask every time" save dialog behavior on macOS (Apple Silicon) across the requested scenarios. Here are the findings:

   1. Presentation & Placement

   • Normal Mode (Windowed / Desktop):

     • The dialog does not attach as an odd sheet or cling to an invisible dot. It appears cleanly centered on the screen as a standard, standalone native dialog window (NSSavePanel / NSOpenPanel).
     • It starts in the source file's directory as expected.
     • Saving to a location succeeds, and pressing Cancel cleanly cancels the operation without triggering any background processing.

   • Full-Screen Space Transition (Important Finding):

     • When Finder or the active application is in macOS Full-Screen mode (which macOS hosts in its own dedicated Space), dropping a file onto the donut causes macOS to immediately slide/switch spaces away from the full-screen app back to the Desktop Space where the host window and dialog are created.
     • Your suspicion about "it could show in an odd place (on another Space)" was spot on: because the invisible 1x1 host window is spawned without full-screen auxiliary collection behaviors, macOS forces a Space switch to reveal the desktop.

   2. Multi-File Drop & Main Window State

   • Dropping multiple files opens the native Folder picker dialog once for the batch instead of repeatedly asking per file.
   • Behavior remains consistent whether Filee's main window is currently open in the background or closed/hidden to the menu bar.

   Here is a screen recording demonstrating the dialog appearance, functionality, and the full-screen Space transition:
   https://youtu.be/_0Rqt9fopjY
5. KnifeLemon commented on Nov 6, 2026

   

   KnifeLemon

   on Nov 6, 2026

   OwnerAuthor

   More actions

   Thanks, @AzrielTheHellrazor, that's exactly what we needed! So the normal case is fine:

   • Placement: a standalone, centred dialog that starts in the source's folder.
   • Several files: one folder picker.
   • Cancel: starts nothing.
   • Main window open or closed: no difference.

   The one problem is full screen: macOS leaves the full-screen Space, because the 1×1 host window (WindowService.AskSaveLocationAsync) has no full-screen collection behaviour. The likely fix is to give that host NSWindowCollectionBehaviorFullScreenAuxiliary and MoveToActiveSpace, as the donut's own window does, and to check that the panel then opens on the full-screen Space.

   Would you like to take it as a PR? We can't try it here, and you've got the setup to check it. #1155 comes first, of course. If you'd rather not, just say so, and this stays open for it.
6. AzrielTheHellrazor commented on Nov 6, 2026

   

   AzrielTheHellrazor

   on Nov 6, 2026

   Collaborator

   More actions

   Hi @KnifeLemon,

   I would be more than happy to take this on!

   I have just pushed the requested updates and posted the test verification results on #1155. Once we finalize and wrap up that PR, I will dive straight into this issue, implement the full-screen auxiliary collection behavior for the host window, and submit a PR for it shortly.

   Thanks again!