URL opening multiple times

[crater2150]

I recently installed another browser and set it as default, since then tmux-url-select opens each url in both browsers. Opening an URL from somewhere else or directly using xdg-open does not show that behaviour, it only opens in the one I set as default.

I found a workaround, I changed COMMAND from xdg-open to a script with the following content:

#!/bin/bash
{
  xdg-open "$@"
} &>/dev/null

Notably, redirecting the output is required. If I don't, tmux-url-select will again open the link in both browsers. I redirected to files to check, if there are any errors in the output, but stdout was empty and stderr contained "09:56:49 INFO: Opening in existing instance". So a nonempty stderr seems to cause the problem.

[xavierog]

I believe I stumbled upon this issue too.
My browser used to issue a locale-related message on stderr:

(Firefox-esr:28416): Gtk-WARNING **: 22:00:57.589: Locale not supported by C library.
        Using the fallback 'C' locale.

Until I fixed it, tmux-url-select used to open each link twice (resulting in two separate tabs showing the same URL).
However, once fixed, I was unable to reproduce the bug again just by outputting stuff on stderr from a wrapper script.

I have investigated the issue further and here are my conclusions so far:

• tmux-url-select calls xdg-open through a simple fork()-and-exec() routine shortly before exiting:

tmux-url-select/tmux-url-select.pl

Lines 135 to 138 in 3665185

	unless (fork) {
	tmux_display_message($message) if VERBOSE_MESSAGES;
	exec $command;
	}

• However, after the fork() and before the exec(), tmux-url-select neither closes nor adjusts the file descriptors (stdin, stdout, stderr) it inherited from the parent process. Consequently, these file descriptors will likely become unusable after tmux-url-select exits. Specifically, syscalls on these file descriptors will return EIO:

[pid 807809] write(2, "Error: write /dev/stderr: input/output error\n", 45) = -1 EIO (Input/output error)
[pid 807517] write(1, "xdg-open: open_generic: no method available for opening 'https://some.url.that/does/not/matter'\n", 91) = -1 EIO (Input/output error)
[pid 807517] write(2, "/usr/bin/xdg-open: 254: echo: ", 30) = -1 EIO (Input/output error)
[pid 807517] write(2, "echo: I/O error", 15) = -1 EIO (Input/output error)
[pid 807517] write(2, "\n", 1)          = -1 EIO (Input/output error)

• Writing anything on stdout and/or stderr does not necessarily mean a process exits with a non-zero return code. However, an EIO when trying to do so significantly increases the odds that it does.
• Enter xdg-open: this shell script essentially tries its collection of heuristics sequentially. These heuristics are based on the current desktop environment, available .desktop files, the BROWSER environment variable and even an embedded list of well-known browsers. But a common pattern is: "if that thing xdg-open just tried exited with a non-zero return code, then it failed and xdg-open should try something else".

This "something else" can be the next browser (likely what happened to @crater2150) or running $BROWSER again (what happened to me).

Consequently, I suggest the following fix:

--- tmux-url-select.pl
+++ tmux-url-select.pl
@@ -134,6 +134,9 @@

     unless (fork) {
         tmux_display_message($message) if VERBOSE_MESSAGES;
+        open(STDIN, '/dev/null');
+        open(STDOUT, '>/dev/null');
+        open(STDERR, '>/dev/null');
         exec $command;
     }
 }

I hereby confirm that toggling this 3-line fix toggles the issue.