System default browser not used, because serverapp started as "opening a local html file"

[MichaelClerx]

Description

On a fresh install of Fedora 41 (gnome 47) I suddenly found that the jupyter notebook command opened chrome, not my system default of firefox. This was really confusing as I couldn't see any configuration files, environment variables or anything else telling it to do this, and webbrowser.open('https://google.com') would load firefox as expected.

Reproduce

Fresh install of recent linux, including multiple browsers.
Change default browser

After a lot of searching, I discovered it was because the default browser used by webbrowser is xdg-open, which will use the system default browser for http://..., but the default application for the .html extension for local files file://....

And because jupyter was starting as
file:///home/michael/.local/share/jupyter/runtime/jpserver-10052-open.html
this was treated as a local "opening a html file" action...

This gets worse, because if you do web development you might want the local "opening a html file" to be opening it in a text editor...

Expected behavior

Expecting notebook to "open a page in the default browser".
Instead it "perfoms the default action for opening a local html file"

Obvious solution would be to use webbrowser.open('http://localhost:8888/tree?...
instead of getting there via a local file?

Context

Operating System and version: Fedora 41
Browser and version: Firefox and chrome
Jupyter Server version: 2.14.2

[minrk]

See jupyter/notebook#4304 for the longstanding report for this, and various things folks have tried, and workarounds you can use. I think if xdg-settings get default-web-browser works, the right thing will happen.

This seems like we should report a bug to the standard library if there isn't one already, because xdg-open is not a safe assumption for file:// URLs.

[minrk]

Opened upstream issue: python/cpython#128540

I think we can work around this if we register our own default browser lookup, but I'm not sure how easy that is going to be. Linux actually seems to be the hardest, since the most standard mechanism I can think of is already used there (xdg-settings get default-web-browser, but I guess it doesn't always work).

What do you get from xdg-settings get default-web-browser btw?

[MichaelClerx]

michael@fedora:~$ xdg-settings get default-web-browser
org.mozilla.firefox.desktop

But it doesn't use the default web browser for .html files: it uses whatever the default application for .html is (so default browser in this case is irrelevant)

[minrk]

Hm, I thought the default-web-browser approach was supposed to be preferred to xdg-open. What do you get from webbrowser.get().name?

And the result of subprocess.check_output(["org.mozilla.firefox.desktop"])?

[MichaelClerx]

xdg correctly loads firefox, and the "name" it reports is not a command:

$ xdg-settings get default-web-browser
org.mozilla.firefox.desktop

$ org.mozilla.firefox.desktop
bash: org.mozilla.firefox.desktop: command not found

$ xdg-open https://github.com --> Opens in firefox

The webbrowser module reports xdg-open as the default:

$ python -c "import webbrowser; print(webbrowser.get().name)"
xdg-open

[minrk]

I think this is a bug in webbrowser's handling of xdg-settings, then, because that's how it tries to look up the default browser. It executes the result of xdg-settings get default-web-browser and then falls back on xdg-open when that fails.

I'm not sure what the right xdg invocation is to say "open this url with this specific application"

[MichaelClerx]

Could even be a bug in xdg-open:

$ xdg-open --manual
Name

   xdg-open - opens a file or URL in the user's preferred
   application

Synopsis

   xdg-open { file | URL }

   xdg-open { --help | --manual | --version }

Description

   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.

where, in my reading, the final bit says a file://... string is a URL, not a file, and should therefore be opened in a browser

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.

[MichaelClerx]

$ org.mozilla.firefox.desktop
bash: org.mozilla.firefox.desktop: command not found

I guess you're meant to use this desktop entry, but that doesn't seem possible in a linux-flavour independent way: https://wiki.archlinux.org/title/Desktop_entries

[MichaelClerx]

On my system you could do gtk4-launch $(xdg-settings get default-web-browser) https://github.com but this only works because the default browser .desktop file is in /usr/share/applications (see website quoted above)

[minrk]

I've been reading into this a bit today, and there doesn't seem to be anything approaching consensus on locating and invoking applications, even on what works and what doesn't.

For example, the limitation about gtk-launch search path doesn't even necessarily seem true, because I just did a fresh install of ubuntu 24.04 and

gtk-launch $(xdg-settings get default-web-browser) file://$PWD/file.html

and it launches firefox.desktop, which resides in /var/lib/snapd/desktop/applications/. It also works for .desktop files in ~/.local/share/applications.

So gtk-launch does seem to work with the output of xdg-settings get default-web-browser, at least sometimes, but I have no idea how general that is (obviously not when gtk-launch is unavailable).

gio launch appears to also work with absolute paths, but not by name. I don't see any simple API that appropriately resolves name.desktop -> /path/to/name.desktop, but I assume it must exist.

[Wulian233]

I made a PR in cpython. python/cpython#130031

All file: will open the browser. But the core dev said:

This is a breaking change. I know of at least one instance where this will cause a significant break: by default the Pythons installed using the python.org macOS installers include a copy of the Python HTML documentation. On macOS, IDLE will look for that copy of the HTML documentation and, if found, will attempt to open it by passing a file: URL to webbrowser.open. Browsing the docs in IDLE is usually invoked with the F1 key. With this PR, pressing F1 causes IDLE to do nothing. There may be other existing users of webbrowser.open that would be similarly affected. I'm not sure what the best solution is but as it stands I don't think we can apply this as is.

This might be a trade-off issue where both can't be achieved. I don't know how to fix it.

[minrk]

I created https://pypi.org/project/webbrowser-open/ implementing default-browser handling, which is wrong in the standard library on all platforms for file:// URLs. It's a prototype intended to go upstream into stdlib webbrowser, but we could start using it in jupyter_server today, if it gets a bit of testing.