Dialog API issue with file selection [bug]  #2153

Activity

1. amrbashir

   added

   platform: macosmacOS specific issuesmacOS specific issues

   on Jul 11, 2023
2. dwosk commented on Jul 30, 2023

   

   dwosk

   on Jul 30, 2023

   More actions

   I'm also seeing this same behavior on macOS. The only workaround seems to be setting a parent window when building the file dialog, which is not ideal. It also makes using the builder a lot less ergonomic (since I need to pass around a window).
3. FabianLars

   transferred this issue fromtauri-apps/taurion Dec 5, 2024
4. FabianLars

   added

   type: bugSomething isn't workingSomething isn't working

   plugin: dialog

   on Dec 5, 2024
5. nicsheen commented on Sep 24, 2026

   

   nicsheen

   on Sep 24, 2026

   More actions

   Root cause, for anyone still hitting this: the dialog has no parent window, and rfd then picks one for itself.

   The plugin only applies a parent if one was set (desktop.rs, if let Some(parent) = d.parent), and the JS OpenDialogOptions has no parent field at all — so every dialog opened from JavaScript arrives with parent: None. rfd then guesses:

   // rfd-0.16.0/src/backend/macos/modal_future.rs
   let win = if let Some(win) = win {
       Some(win)
   } else {
       unsafe { app.mainWindow() }.or_else(|| app.windows().firstObject())
   };
   
   // if async exec is possible start sheet modal
   if unsafe { app.isRunning() } && win.is_some() {
       inner.begin_modal(&window.0, &completion);
   }

   and for the file panel begin_modal is beginSheetModalForWindow_completionHandler (file_dialog/panel_ffi.rs). So the panel is presented as a sheet on whatever that guess produced. mainWindow() is nil whenever the app isn't key — including immediately after a menu item is clicked — so it falls through to app.windows().firstObject(), which is arbitrary.

   A sheet attached to the wrong window looks exactly like the screenshot above: pinned somewhere unexpected and impossible to move, because sheets can't be moved.

   We hit a worse variant of the same thing on macOS 26.6.2: with the intended window full-screen, the sheet landed on a different window, which for a full-screen window means a different Space. The app was modally blocked by a panel that was nowhere on screen, and Escape was the only way out. Intermittent, because it depends on whether mainWindow() happens to be nil and on the ordering of app.windows().

   Workaround until #2563 lands — don't open the dialog from JS; wrap it in your own command and name the parent:

   #[tauri::command]
   pub async fn pick_open_path(window: tauri::Window) -> Option<String> {
       window
           .dialog()
           .file()
           .set_parent(&window)
           .blocking_pick_file()
           .and_then(|p| p.into_path().ok())
           .map(|p| p.to_string_lossy().into_owned())
   }

   (async so Tauri runs it off the main thread, which is what makes blocking_* safe here.) With the parent named, the sheet attaches to the invoking window every time — verified via the accessibility tree, where the panel now shows up as an AXSheet child of the right window.

   Message dialogs go through the same ModalFuture fallback, so they need .parent(&window) too.