Inconsistent behaviour on UNIX platforms
amodm opened this issue · comments
The current behaviour on Unix uses BROWSER
env, followed by xdg-open
and a bunch of other programs. Some of these programs are blocking in nature, e.g. x-www-browser
, while others, e.g. firefox
aren't. Also, if the fallback in xdg-open
reaches a text browser (e.g. lynx
etc.), it will definitely be a blocking call.
Define a consistent behaviour on UNIX platforms, irrespective of the underlying browser being used.
xdg-open
does not background the process by default: https://unix.stackexchange.com/questions/74605/use-xdg-open-to-open-a-url-with-a-new-process
This causes cargo test
to fail when run on a headless platform, since xdg-open
will (as OP says) open up a text browser in blocking mode.
Noted @infinity0. I've not yet gotten around to figure out how to create a consistent behaviour on this, and fixing tests appropriately.
Is there a workaround for this?
I tried spawning in a background thread, but it doesn't open the browser:
thread::spawn(move || {
if webbrowser::open("https://github.com").is_ok() {
println!("It opened.")
}
});
Ok, you have to wait for it to finish:
let t = thread::spawn(move || {
if webbrowser::open("https://github.com").is_ok() {
println!("It opened.")
}
});
// rest of your code here
// add the subthread back to the main thread
t.join().unwrap()
@zwhitchcox, looks like you've found a workaround? Just for my understanding, could you share what's the scenario where this has become blocking?
@amodm correct..I'm on Ubuntu Focal 20.04, and just using the exact same code as in my post, and it opens the Chrome browser.
I can give you more details if you want too, I'm just not sure what else you might need.
This is also not a complete work around, because you still have to rejoin the thread to the main process, which blocks, and the process won't exit.
So, I guess a complete workaround would involve killing the spawned thread after a certain timeout or something.
I also figured out it's using xdg-open in the background.
I agree. The only way I'm able to currently think of is to actually parse PATH
env variable, and determine which underlying executable is invocable, and spawn it in a background non-blocking way. I'm hoping to get around to doing this soon, but happy to take a PR if you feel up to it.
This has been addressed in 614cacf4a67ae0a75323768a1d70c16d792a760d