Browser integration fails if you run cmd before picking a file (kitty, konsole, wezterm)

[serranomorante]

• Operating System: archlinux
• Desktop Environment: kde plasma
• Terminal Emulator: kitty
• Shell: bash
• Custom desktop opener (if applicable): yes

[Desktop Entry]
Type=Application
Name=nnn
Comment=Terminal file manager
Exec=nnn
Terminal=true
Icon=nnn
MimeType=inode/directory
Categories=System;FileTools;FileManager;ConsoleOnly
Keywords=File;Manager;Management;Explorer;Launcher

#!/bin/sh
XDG_CURRENT_DESKTOP=KDE chromium "$@"

• Program options used: nnn -JRHdaA -Tt -p - '$file' ...
• Configuration options set: O_NERD=1
• Plugins are installed: preview-tui, nmount, umounttree, dragdrop
• Issue exists on nnn master: yes

Exact steps to reproduce the issue

I believe you don't need all my config and nnn plugins to be able to replicate this. These are the steps:

1. Implement the browser integration example from here, for chromium based browsers like chrome, brave or chromium.
2. Now open your browser and press Control+o to "open a file". This should open the nnn picker.
3. Before pressing enter on any file, first run Control+] to open the shell. You don't have to execute anything in here, just write exit
4. Now press enter on any file.

The browser will try to open a non existent file. This doesn't happen if you don't enter the cmd mode with Control+] first.

The reason I need to enter the cmd mode before picking a file is to perform a cd <path> manually to find the file (because I might have copy the absolute path from other app).

These are the terminal emulators that present the issue when you use them in the kdialog script.

Terminal	works?
st	yes ✅
kitty	no ❌
konsole	no ❌
wezterm	no ❌

#!/bin/sh

while :; do case $1 in
    --getsavefilename) file="$2" break ;;
    --version) printf ""; exit ;;
    --*) shift ;;
    *) break ;;
esac done

file="${file##/*/}"

# st -c picker sh -c ...
# konsole -e sh -c ...
# wezterm start --class picker -- sh -c ...
kitty --class picker sh -c "nnn -JRHdaA -Tt -p - '$file' | awk '{ print system(\"[ -d '\''\"\$0\"'\'' ]\") ? \$0 : \$0\"/$file\" }' > /proc/$$/fd/1"

[serranomorante]

I just tried st instead of kitty in the kdialog script and that seems to work. Is this a problem with kitty terminal specifically? I will try to debug this a little further.

this is the one that fails

#!/bin/sh

while :; do case $1 in
    --getsavefilename) file="$2" break ;;
    --version) printf ""; exit ;;
    --*) shift ;;
    *) break ;;
esac done

file="${file##/*/}"

kitty --class picker sh -c "nnn -JRHdaA -Tt -p - '$file' | awk '{ print system(\"[ -d '\''\"\$0\"'\'' ]\") ? \$0 : \$0\"/$file\" }' > /proc/$$/fd/1"

• st works
• kitty fails
• konsole fails
• wezterm fails

[N-R-K]

What happens if you run this command from a terminal

kitty --class picker sh -c "nnn -JRHdaA -Tt -p - '$file' | awk '{ print system(\"[ -d '\''\"\$0\"'\'' ]\") ? \$0 : \$0\"/$file\" }' > /proc/$$/fd/1"

Is kitty printing something? The file dialogue thing requires the selected file to be printed to stdout so if kitty is printing it's own stuff then that could be the reason why.

[serranomorante]

# In this dialog I used Ctrl+] (to enter shell) before pressing enter on a file
[serranomorante@arch playbooks]$ kitty --class picker sh -c "nnn -JRHdaA -Tt -p - '$file' | awk '{ print system(\"[ -d '\''\"\$0\"'\'' ]\") ? \$0 : \$0\"/$file\" }' > /proc/$$/fd/1"
[0.215] [glfw error 65544]: process_desktop_settings: failed with error: [org.freedesktop.DBus.Error.ServiceUnknown] The name is not activatable
/home/serranomorante/dotfiles/playbooks/ansible.cfg

# On this one I pressed enter on the file (without entering the shell)
[serranomorante@arch playbooks]$ kitty --class picker sh -c "nnn -JRHdaA -Tt -p - '$file' | awk '{ print system(\"[ -d '\''\"\$0\"'\'' ]\") ? \$0 : \$0\"/$file\" }' > /proc/$$/fd/1"
[0.231] [glfw error 65544]: process_desktop_settings: failed with error: [org.freedesktop.DBus.Error.ServiceUnknown] The name is not activatable
/home/serranomorante/dotfiles/playbooks/ansible.cfg

wezterm also shows a very similar output

The thing is, the second option still works (the browser is able to open the file normally).