linebender/druid · error
No path received for filename
Error message
No path received for filename
What it means
In druid-shell's GTK file dialog backend, when the chooser dialog is accepted (`ResponseType::Accept`) the code reads `dialog.filenames()`. If the user accepted but GTK returned no filenames, there is no path to return, so the function yields an anyhow error 'No path received for filename'.
Solutions
- Check the returned Result and show the file dialog again instead of unwrapping, treating this as a user cancellation
- Verify with a real file selected that the dialog works; if it reproduces on plain accept, update druid-shell/GTK (known platform quirks)
- Guard downstream code against empty results before using the chosen path
Example fix
// before
let path = file_dialog(...).unwrap();
// after
match file_dialog(...) {
Ok(path) => use_path(path),
Err(_) => { /* treat as cancelled, no-op */ }
} Defensive patterns
Strategy: try-catch
Validate before calling
let paths: Vec<PathBuf> = dialog.filenames();
if paths.len() == 1 { use_path(paths[0].clone()); } Try / catch
match result { Err(e) if e.to_string().contains("No path received") => { /* treat as cancelled */ }, other => other } Prevention
- Never unwrap file dialog results
- Treat dialog errors as cancellation in UX flow
- Test dialogs in your target GTK environment (sandboxes behave differently)
When it happens
Trigger: User clicks OK/Open/Save on a FileDialog while the chooser holds no selected file — e.g. pressing Enter or the accept button with an empty selection, or a GTK edge case where the dialog closes as accepted without a selection.
Common situations: Users pressing Enter on an empty file chooser; non-interactive/scripted GTK environments (CI, flatpak sandboxes) where dialog selection behaves unexpectedly; custom GTK dialogs returning Accept on close.
Understand the failure class
Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.
Related errors
- More than one path received for single selection
- Tried to build a window without setting the handler
- The main thread status has already been claimed by thread
- acquire_input_lock was called on a WinHandler that did not…
- release_input_lock was called on a WinHandler that did not…
AI-assisted analysis of linebender/druid@0f8b1195e4 (2026-09-10).
Data as JSON: /api/errors/e89925763b58071f.
Report an issue: GitHub.
Appendix: source
Thrown at druid-shell/src/backend/gtk/dialog.rs:90
}
}
if let Some(dt) = &options.default_type {
if !found_default_filter {
tracing::warn!("The default type {:?} is not present in allowed types.", dt);
}
}
}
if let Some(default_name) = &options.default_name {
dialog.set_current_name(default_name);
}
let result = dialog.run();
let result = match result {
ResponseType::Accept => match dialog.filenames() {
filenames if filenames.is_empty() => Err(anyhow!("No path received for filename")),
// If we receive more than one file, but `multi_selection` is false, return an error.
filenames if filenames.len() > 1 && !options.multi_selection => {
Err(anyhow!("More than one path received for single selection"))
}
// If we receive more than one file with a save action, return an error.
filenames if filenames.len() > 1 && action == FileChooserAction::Save => {
Err(anyhow!("More than one path received for save action"))
}
filenames => Ok(filenames.into_iter().map(|p| p.into_os_string()).collect()),
},
ResponseType::Cancel => Err(anyhow!("Dialog was deleted")),
_ => {
tracing::warn!("Unhandled dialog result: {:?}", result);
Err(anyhow!("Unhandled dialog result"))
}
};
// TODO properly handle errors into the Error typeView on GitHub (pinned to 0f8b1195e4)