m1k1o/neko · error
unable to select files in dialog
Error message
unable to select files in dialog
What it means
HandleFileChooserDialog automates the native GTK 'Open File' dialog by driving it with xdotool keystrokes (typing the URI, pressing Return). After the automation sequence it re-runs `xdotool search --name "Open File"`; if that search still succeeds, the dialog window is still present, meaning the file selection did not complete, so this error is returned. It is a heuristic (not a native API) check that the simulated interaction failed to close the dialog.
Source
Thrown at server/internal/desktop/filechooserdialog.go:58
"key", "Down",
"key", "--clearmodifiers", "ctrl+a",
"key", "Return",
"sleep", fileChooserDialogLongSleep,
).Run()
if err1 != nil {
return err1
}
// TODO: Use native API.
err2 := exec.Command(
"xdotool",
"search", "--name", fileChooserDialogName,
).Run()
// if last command didn't return error, consider dialog as still open
if err2 == nil {
return errors.New("unable to select files in dialog")
}
return nil
}
func (manager *DesktopManagerCtx) CloseFileChooserDialog() {
for range fileChooserDialogCloseAttempts {
mu.Lock()
manager.logger.Debug().Msg("attempting to close file chooser dialog")
// TODO: Use native API.
err := exec.Command(
"xdotool",
"search", "--name", fileChooserDialogName, "windowfocus",
).Run()
if err != nil {View on GitHub (pinned to b0f01cedea)
Solutions
- Retry the file selection request once, then verify with IsFileChooserDialogOpened; transient focus/timing issues often succeed on a second attempt.
- If the dialog is stuck, call CloseFileChooserDialog (which force-closes it with Alt+F4) and retry the upload.
- Ensure xdotool is installed and the server has access to the X display (DISPLAY set, XAUTHORITY correct) so keystrokes actually reach the dialog.
- Check the dialog window title matches 'Open File' (the constant fileChooserDialogName); localized desktop environments or other GTK dialogs may need the constant adjusted.
- Increase reliability by running the server in a desktop environment whose file chooser matches the assumed GTK flow, or replace the xdotool hack with a native dialog API.
Example fix
// before: blind retry that fails again when dialog is stuck
if err := desktop.HandleFileChooserDialog(uri); err != nil {
return err
}
// after: close stuck dialog, then retry once
if err := desktop.HandleFileChooserDialog(uri); err != nil {
desktop.CloseFileChooserDialog()
if err := desktop.HandleFileChooserDialog(uri); err != nil {
return err
}
} Defensive patterns
Strategy: retry
Validate before calling
if !desktop.IsFileChooserDialogEnabled() {
return errors.New("file chooser dialog is not enabled on this server")
}
if desktop.IsFileChooserDialogOpened() {
desktop.CloseFileChooserDialog() // clear a stuck dialog first
} Try / catch
err := desktop.HandleFileChooserDialog(uri)
if err != nil {
if err.Error() == "unable to select files in dialog" {
desktop.CloseFileChooserDialog()
err = desktop.HandleFileChooserDialog(uri) // one retry
}
if err != nil {
log.Printf("file selection failed: %v", err)
}
} Prevention
- Verify xdotool is installed and DISPLAY/XAUTHORITY are set in the container/VM.
- Confirm the guest desktop's file dialog window title is 'Open File' (avoid localized desktops or adjust the constant).
- Check IsFileChooserDialogEnabled before attempting file selection.
- Close any already-open dialog (CloseFileChooserDialog) before issuing a new selection.
- Prefer minimal desktop environments whose GTK dialog matches the assumed automation flow.
When it happens
Trigger: Calling the file-chooser upload endpoint (HandleFileChooserDialog) when the GTK 'Open File' dialog remains open after the xdotool automation: wrong window name/title match, keystrokes not delivered (window never focused), the typed URI being rejected by the dialog, autocomplete suggestions intercepting the Return key, or xdotool working but the dialog staying open for another reason.
Common situations: Running neko in environments where xdotool cannot reach the X display or the dialog has a localized/different title than 'Open File'; desktop environments (e.g. GNOME variants) whose file dialog behaves differently from the assumed flow; slow VMs where the fixed 0.2s/0.4s sleeps are too short; multi-monitor or focus-stealing-prevention setups that keep the dialog unfocused.
AI-assisted analysis of m1k1o/neko@b0f01cedea (2026-09-01).
Data as JSON: /api/errors/204df55f703c582b.
Report an issue: GitHub.