Giters

amodm / webbrowser-rs

Rust library to open URLs in the web browsers available on a platform

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inconsistent behaviour on UNIX platforms

amodm opened this issue · comments

commented

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.

commented

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.

commented

Noted @infinity0. I've not yet gotten around to figure out how to create a consistent behaviour on this, and fixing tests appropriately.

commented

Is there a workaround for this?

commented

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.")
    }
  });
commented

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()
commented

@zwhitchcox, looks like you've found a workaround? Just for my understanding, could you share what's the scenario where this has become blocking?

commented

@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.

commented

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.

commented

I also figured out it's using xdg-open in the background.

commented

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.