Hello 👋

I run a security community that finds and fixes vulnerabilities in OSS. A researcher (@offalltn) has found a potential issue, which I would be eager to share with you.

Could you add a SECURITY.md file with an e-mail address for me to send further details to? GitHub recommends a security policy to ensure issues are responsibly disclosed, and it would help direct researchers in the future.

Looking forward to hearing from you 👍

(cc @huntr-helper)

crashes in the simulator right away and on device on second call:

#1	0x00000001853f1a4c in -[UIApplication _openURL:options:completionHandler:] ()
#2	0x0000000104bd7754 in _$LT$$LP$A$C$B$C$C$RP$$u20$as$u20$objc..message..MessageArguments$GT$::invoke::h723bf370353936c5 [inlined] at /Users/stephan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:128
#3	0x0000000104bd7744 in objc::message::platform::send_unverified::h633786a288498e5d [inlined] at /Users/stephan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/apple/mod.rs:27
#4	0x0000000104bd7744 in objc::message::send_message::h51c0bf550976ad86 [inlined] at /Users/stephan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:178
#5	0x0000000104bd7744 in webbrowser::os::open_browser_internal::h265347fd9891411b at /Users/stephan/code/webbrowser-rs/src/ios.rs:34
#6	0x0000000104bd6ee8 in webbrowser::open_browser_with_options::h4f9ae24e53e16fcc [inlined] at /Users/stephan/code/webbrowser-rs/src/lib.rs:331
#7	0x0000000104bd6eb8 in webbrowser::open_browser::h7ea0b174943835c6 [inlined] at /Users/stephan/code/webbrowser-rs/src/lib.rs:298
#8	0x0000000104bd6eb8 in webbrowser::open::h36cf092bc1244f75 at /Users/stephan/code/webbrowser-rs/src/lib.rs:283

Most browsers won't run as root, so as part of a program running as root it'd be useful to be able to specify that the browser should be opened as another user.

Thanks for adding the fallback to the $BROWSER environment variable.

However, unlike $PAGER and $EDITOR, $BROWSER doesn't always consist of a single command name that you can run with an URL argument. Quoting man 1 man (one of a few sources fully documenting $BROWSER):

If $BROWSER is set, its value is a colon-delimited list of commands, each of which in turn is used to try to start a web browser for man --html. In each command, %s is replaced by a filename containing the HTML output from groff, %% is replaced by a single percent sign (%), and %c is replaced by a colon (:).

See the documentation for the Python webbrowser module for another explanation of $BROWSER.

So:

• Split $BROWSER on ':' and loop over each, continuing to the next on failure
• For each one, replace '%s' with the URL, '%c' with a colon, and '%%' with a percent. If and only if it didn't contain '%s', append the URL.

So I have tested this with Firefox, Chrome and notably Min browser (which is the one i personally use). I changed my default browser each time when running my rust code and firefox and chrome work fine, however min browser displays "An error occurred (-102)" but if i refresh the page it loads properly.

I'm not sure if this a fault with webbrowser-rs or min but i thought i would put this issue up anyway just in-case.

can you please add support for wasm?

On Linux, opening the default browser uses xdg-open, part of xdg-utils; however, nothing in a default desktop install requires the installation of xdg-utils. Please consider supporting some fallbacks, such as gvfs-open, or parsing the $BROWSER environment variable directly.

Just as the title says, I would love it if there was a way to detect if a browser is available without having to open a url.

I have an app that can be run in docker, where a browser is not available. If possible I'd like t remove the web feature from my app, but I can't easily detect if a browser is available without attempting to open a url.

When I try to run the following example code, it results in the program panicking with the message below:
Code:

fn main() {
    webbrowser::open("http://github.com").unwrap();
}

Error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }'

I'm guessing it could be because my browser is located at C:\Program Files\.....\firefox.exe which has a space in its path.
Maybe that's messing up the command that's being executed?

The title is pretty self-explanatory. I'm on macOS 10.14.2 and Ubuntu 18.10.

This is weird to me because $BROWSER is not set and xdg-open is also non-blocking. I'm not really sure why but in any case it would be nice to have consistent behavior across platforms.

In my case on Linux the call to xdg-open causes Opening in existing browser session to be printed to the console. Would it make sense to silence all output of the external tools by default unless there's an error?

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 webbrowser-rs Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @amodm

It will be very easy to just send commands to launch the webrowser , also more options can be implemented

Reasons to do so:

1. Current API has been stable for a while
2. Consistent behaviour is defined reasonably strictly, and seems unlikely to change for a while
3. As per pre-release guidelines of Cargo, It is recommended to not use pre-release dependencies in a library if your library is not also a pre-release, so this should make for easier decision to include in your manifest.

Hi, I'm not sure if I'm doing something wrong here since I just started using this library. I have previously used the python webbrowser library before, though.

I'm on Windows 10

Note that Microsoft Edge does not have this issue.

I briefly looked at the Windows code and I'm guessing you need to specify https as the URI protocol scheme/lpClass argument when using a https URLs (currently it always specifies http), but I haven't tested whether that fixes it.

I usually use the Python webbrowser library, and that can open https links fine in Firefox.

Opening HTTP:// links

The following works fine for me on Firefox/Chrome. When I use the link http://github.com, it opens https://github.com

fn main() {
    webbrowser::open("http://github.com").unwrap(); // HTTP link
}

Opening HTTPS:// links

However, if I use the link https://github.com, it opens some sort of temporary file related to the website being opened:

file:///C:/Users/drojf/AppData/Local/Microsoft/Windows/INetCache/IE/5M7ZY6EG/2F611R12

On Firefox, this actually shows a github page, but it is as if I'm not logged into github, so I'm guessing it's opening a temporary file from Microsoft Edge

fn main() {
    webbrowser::open("https://github.com").unwrap(); // HTTPS link
}

Firefox:

Chrome:

In most of my web applications, it would be more convenient to have target set to _blank.
It would be great to have that option, or probably it's even worth to consider it as a default behaviour.

Is there anyway to run this command silently? I'm writing a terminal program, and whenever it opens the browser, it outputs a bunch of stuff to the console:

(chrome:393290): Gtk-WARNING **: 14:08:45.919: Theme parsing error: gtk.css:1566:23: 'font-feature-settings' is not a valid property name

(chrome:393290): Gtk-WARNING **: 14:08:45.922: Theme parsing error: gtk.css:3616:25: 'font-feature-settings' is not a valid property name

(chrome:393290): Gtk-WARNING **: 14:08:45.922: Theme parsing error: gtk.css:4078:23: 'font-feature-settings' is not a valid property name
Opening in existing browser session.

Is there any way to get rid of that? I don't care if it fails, because I'm going to be pasting the URL to the console anyway as a backup.

The ndk-glue crate (like any Android glue crate) is unlike most Rust libraries in the way that it's not possible to link more than one version into an Android application and it's also not compatible with any other glue crates (since these crates are responsible for providing the main entrypoint for the application).

Depending on ndk-glue here means that any downstream Android application has to use this exact version of ndk-glue which can either conflict with another glue layer that the application wants to use (such as android-activity) or else it may conflict with frameworks like Winit that will also depend on specific versions of the glue crate.

To solve this source of conflicts the ndk-context crate was created earlier this year. ndk-context provides a minimal library that lets you access the JVM and make JNI calls without imposing any constraint on what glue layer an application uses (different glue layers such as ndk-glue will initialize the state for this library).

I haven't had a chance to investigate the code here yet but I expect that this crate should be able to switch to using the ndk-context crate instead of ndk-glue and therefore be more compatible with Android applications.

I came here after seeing one of my Android applications start to panic due to it unexpectedly bringing in the ndk-glue crate which I'm not using.

Happy to also take a look at making a PR for this.

Currently, if target_arch="wasm32", calls to webbrowser::open will open in the same tab/window, and there's no way to programmatically open a link in a new tab.

As of now, the two publicly exposed functions are:

• fn open(url: &str) -> Result<Output>, as seen here, and
• fn open_browser(browser: Browser, url: &str) -> Result<Output>, as seen here

This causes issues of two kinds:

1. Not all runtime environments provide Output, e.g. when built for the wasm32, the signature ends up being fn open(url: &str) -> Result<()> as seen here, so we end up having different signatures for different environments.
2. The current Output is not useful at all, which reflects in a (unscientific) review of usages of this library across Github. It's easy to see why - there's not much that a client can do differently based on the response. So everyone ends up using the return value effectively as a Result<()>.

Given the above, it's probably best to modify the signature to:

• fn open(url: &str) -> Result<()>, and
• fn open_browser(browser: Browser, url: &str) -> Result<()>

Hello, your crate works well on the Meta Quest VR Headset. As you can see here : https://youtu.be/28H67HftB_E

On the Quest devices this could allow to open a dozen 2D applications such as the Browser, YouTube 2D, the parameters etc ... over a VR application in progress,

Would it be possible to extend your code to other configurable applications? If not, do you allow me to take up your code to adapt it to my project under MIT license.

I believe this code should be sufficient : https://github.com/amodm/webbrowser-rs/blob/main/src/android.rs

Thanks.

If you're going to support gvfs-open and gnome-open to solve #2 in situations where xdg-utils hasn't been installed and $BROWSER is unset, then I suggest adding the following two things to your fallback chain:

1. kioclient exec <URL> (KDE's equivalent to gvfs-open)
2. x-www-browser <URL> (This should go at the end of the fallback chain. On Debian-family systems (eg. Ubuntu, Mint), it invokes whatever browser is configured as default at the system-wide level and, as it's maintained by the package manager, it's guaranteed to be present and valid as long as at least one browser is installed... even if that means falling bact to lynx or links in a terminal.)

Also, if you want to be a little bit smarter in mixed installations, check whether the XDG_CURRENT_DESKTOP environment variable says KDE to determine whether kioclient exec <URL> should come before or after the g... ones in the precedence order.

Possible to publish a new release of the crate?

We are specifically after the Android support that came in #19

Trying the below

fn main() {
webbrowser::open("https://google.com").unwrap()
}

web browser is not opening

Firefox is my default browser

/usr/bin/firefox

Mozilla Firefox 125.0.1

My OS version:

NAME="Linux Mint"
VERSION="21.3 (Virginia)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21.3"
VERSION_ID="21.3"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=virginia
UBUNTU_CODENAME=jammy

Could you please help

I found this out by accident, when troubleshooting a problem with someone else's application, but hey! I know what the issue is (Although, I do not know how to fix it, I can at least identify it!)

How to reproduce this issue:

gedit ~/.config/mimeapps.list (you can use any text editor, really, I just chose gedit)

Once open, under [Default Applications] replace the line containing text/html= with text/html=gedit.desktop
If the line does not exist, add text/html=gedit.desktop instead. (Again, any text editor with a .desktop file will do.

Now that that's set up, use the function that calls: open_browser_internal, and is a standard file system path to an html document.
Example: /home/username/index.html
This will instead open up the file in the text editor you chose.

The problem is this: https://manpages.ubuntu.com/manpages/focal/man1/xdg-open.1.html

xdg-open opens a file or URL in the user's preferred application. If a URL is provided the
URL will be opened in the user's preferred web browser. If a file is provided the file
will be opened in the preferred application for files of that type. xdg-open supports
file, ftp, http and https URLs.

This means that if a file path is provided rather than a URL, and is a valid mime type, it will open the related non-browser application instead. This is definitely an edge case, but hey, it didn't open the default browser!

When I try to run a very simple minimal reproducible example

use webbrowser;

fn main() {
    if webbrowser::open("http://github.com").is_ok() {
        println!("hello, github.com");
    }
}

With webbrowser = "0.8.1" as the only dependency

# can be run on termux (rust required, `pkg install rust`)
# cargo install sample_webbrowser --git https://github.com/phanirithvij/sample_webbrowser && RUST_BACKTRACE=full sample_webbrowser

The output is

thread 'main' panicked at 'android context was not initialized', /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/ndk-context-0.1.1/src/lib.rs:72:30

For projects such as bevy_egui, it would be useful to be able to choose the target when opening a url.
I saw that it can be changed at compile time, but it's not enough for this use case, egui provides a Hyperlink widget which, in order to behave and feel like a native hyperlink needs to open in _self when left clicking and _blank when using modifiers.

In these conditions:

• On macOS.
• Firefox is your default browser.
• Your destination URL looks like this: https://vercel.com/turborepo/token?redirect_uri=http://127.0.0.1:9789
• You attempt to launch a browser window using webbrowser-rs.
• You get directed to view-source:https://vercel.com/turborepo/token?redirect_uri=http://127.0.0.1

Somewhere in the path from leaving webbrowser-rs (which successfully parses using Url::parse) and navigating to the URL it appears that there is a parsing failure which results in a misinterpretation of the URL.

For bonus points, it is not a consistent failure. I believe that it is related to Firefox being in the middle of a self-upgrade. We have two user reports of this behavior with it resolving itself following completion of the upgrade.

I can reproduce it consistently.

The code that calls it is here:
https://github.com/vercel/turbo/blob/4d07f1a9d139f4d697a54a8629a9bab072b4999c/crates/turborepo-lib/src/commands/login.rs#L122

If xdg-open exists on a system but fails at opening a browser, the fallbacks are not tried.

Steps to reproduce:

1. For testing purposes, add an xdg-open command to your path that does exit 1.
2. Launch the tests, and they will fail

Problem

The run_command function accepts the parameter background: bool:

This enables us to run the command in the background in a newly spawned child process.

Meaning it does not block the execution of the current program.

However, because we don't block the execution of our thread, we won't know about the success of the execution - thus, we will never try any fallbacks, as it'll always be called a success, whether it is or not.

Case where this can happen in the wild

I am running windows and developing inside a WSL machine. There I have xdg-open installed, though it does not support WSL.
Though this is not the case for all WSL machines, it seems. I am running two different distros, and in one, xdg-open does open the browser and everything else, while in the other, it doesn't - not that this is special for the Linux world ..... anyway.

Possible solutions

On the client side:

• Use something like wsl-open or xdg-open-wsl.
• Make it work in other ways, like on one of my WSL machines through magic (I have no idea what config is different)
• Uninstall xdg-open (though it's shipped through xdg-utils and other packages that may require it)

On webbrowser-rs's side

• Try through one of the alternative methods first. They are all rather specific, whereas xdg-open is quite widely used and thus more general. As I don't know the quality of the other tools, it's hard to say for me that is, whether or not they are viable alternatives on systems that have both installed.
• Add the background: bool to the BrowserOptions so that one can set it manually and enforce command exit code check, resulting in a proper fallback chain

Similar to issue #13, I observed, that under Windows open_browser()-calls return immediately, while the same call under Linux blocks.

In my opinion they all should block. This way the caller gets to know when the browser is closed by the user. This way also use cases where blocking is not wanted, are covered easily: just launch a thread and call open_browser().

When using Python's webbrowser.open() for a discord:///channels/.../... uri scheme, everything functions as you would expect. It immediately opens discord.

When using your Rust library, it opens an empty chrome window.

System: Windows 10
Default Browser: Chrome Version 122.0.6261.129 (Official Build) (64-bit)
webbrowser = "0.8.13"

When opening a browser with the following url https://accounts.spotify.com/authorize?response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fcallback&client_id=x&state=y&scope=user-read-recently-played the browser opens successfully but instead of landing on the expected url, the browser lands here https://accounts.spotify.com/authorize?response_type=code.
Cutting off everything after the "&" character.

When trying to reproduce this using the command from here:

I get the same result and the following output:

C:\Users\solomon>start https://accounts.spotify.com/authorize?response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fcallback&client_id=x&state=y&scope=user-read-recently-played
'redirect_uri' is not recognized as an internal or external command,
operable program or batch file.
'client_id' is not recognized as an internal or external command,
operable program or batch file.
'state' is not recognized as an internal or external command,
operable program or batch file.
'scope' is not recognized as an internal or external command,
operable program or batch file.

However, with the help of this, changing the command to the following seemed to work for me:

C:\Users\solomon>start "" "https://accounts.spotify.com/authorize?response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fcallback&client_id=x&state=y&scope=user-read-recently-played"

Let me know if any more info needed.

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.

I think it would be cool to have the possibility to open the webbrowser in a small window,
and for ex. in the middle of the screen.

Would be useful for oauth and oidc auth flows.

Would a pr be welcome?

Webbrower on Windows uses "start link URL" which in Powershell on Windows 10 returns error "The system cannot find the file specified". After testing it seems the problem might be with link part.

This proposes many different answers, some (e.g. "Start-Process -Path URL") don't work any more or default to Internet Explorer.

VS Code uses this environment variable to allow opening a browser over ssh.

webbrowser-rs respects $BROWSER on Linux and works well over a remote connection there. However, on Windows it does not.

A very large amount of GNU/Linux applications use the Flatpak packaging format, which, apart from other features, runs the packaged application inside a container. This causes a problem with this crate however, where the browser cannot be located.

Even if specifying full access to the filesystem in the build manifest, some directories are by definition inaccessible to the application, as well as any other Flatpak application available.

There are three solutions to this:

• Require the user to have a browser natively installed.
• Require the developer to ship their own browser (Afaik this is what Electron does with Flathub, however I am not sure so feel free to correct me)
• Or, just make the developer display their webpage in-app as a fallback, which probably requires another crate entirely, and probably one of the two options as well.

I had the issue, that the URL was treated as a file link, if it contains a space at the end.

For example:

My URL is let url = "http://example.com/foo ".
When I call webbrowser::open(url), I get the error The file /path/to/current/directory/http:/example.com/foo does not exist..

Maybe there should be some kind if URL validation to determine, if the given String is actually a valid URL?
Or maybe some logic that determines, if the given str is a file path and then converts it to an actual file:// path?