8000 gh-128540: launch default browser more often on Linux by minrk · Pull Request #130541 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

gh-128540: launch default browser more often on Linux #130541

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

gh-128540: launch default browser more often on Linux #130541

wants to merge 5 commits into from

Conversation

minrk
Copy link
Contributor
@minrk minrk 8000 commented Feb 25, 2025 •
edited
Loading

especially for file:// URLs

  • add support for gtk-launch and gio launch if default browser is found via xdg-settings, since these allow launching a .desktop by name (gio launch requires an absolute path, so an implementation of searching XDG_DATA is included, while gtk-launch searches XDG_DATA path itself and only needs a name)
  • add support for exo-open --target WebBrowser on XFCE (nice: it allows specifying that a browser should be launched)
  • explicitly prevent non-browser launchers like xdg-open, gvfs-open, gio open from launching file:// URLs, since those open applications associated by file type instead of browsers.

Addresses gh-128540 on linux, etc.

gh-50920: addressed by adding support for exo-open --launch WebBrowser on XFCE (only identified via the standard XDG_CURRENT_DESKTOP, which seems appropriate in 2025)

For users where xdg-settings get default-web-browser returned an exact match to one of the known browsers, there is no change in behavior. For users with gtk-launch or gio launch, any .desktop should work (e.g. the google-chrome-work example in gh-108172), not just those in the hardcoded list.

Note that unlike the mac and Windows implementations, this opts out of file:// URLs for generic launchers instead of opting them in for http[s]. This only has an effect on other URLs, like ssh://, for which behavior is still undocumented. But it is easy enough to make the switch from _supports_file to _http_only (or _supported_protocols)

Questions:

  • should gtk-launch be gnome specific?
  • should gio launch be included, since it requires implementing a search of $XDG_DATA paths (aside: is there a standard call for resolving a .desktop file?)?
  • should xdg-open and friends should be skipped for file URLs, since it does the wrong thing and is top priority in most cases?
  • should xdg-open and friends be restricted to http[s] URLs to avoid launching non-browsers for custom URLs, as is done on mac/Windows and when the default browser is successfully recognized on linux?

Links:

📚 Documentation preview 📚: https://cpython-previews--130541.org.readthedocs.build/

@minrk
webbrowser: launch default browser more often on linux
bf271b7 
especially for file:// URLs

- add support for `gtk-launch` and `gio launch` if default browser is found via `xdg-settings`
- add support for `exo-open --target WebBrowser`
- explicitly prevent xdg-open and other non-browser-specific openers from launching `file://` URLs
@bedevere-app bedevere-app bot mentioned this pull request Feb 25, 2025
Open
@hugovk hugovk changed the title gh-128540: launch default browser more often on linux gh-128540: launch default browser more often on Linux Feb 25, 2025
@minrk minrk mentioned this pull request Feb 25, 2025
Open
@eli-schwartz
Copy link
Contributor

With regard to all of your questions:

In general the DE specific opener command is preferred as it will do DE specific things such as e.g. record opened files in "recently opened" lists and whatnot. xdg-open will proxy out to those commands by doing DE detection, so there's no reason to even consider various *-open programs other than xdg-open except if you don't trust xdg-open to perform said browser detection (or from within a DE-specific component calling out to other parts of said DE).

gio launch and gtk-launch won't exist on all systems. In particular, systems without gnome installed. Such as KDE. What's the story for supporting KDE?

gtk-launch will be called "gtk4-launch" on various gnome systems depending on whether one has gtk 3 or 4.

The best way to handle this is actually just to go ahead and implement the Desktop File Specification and parse the Exec= line yourself then directly execute the relevant command.

@eli-schwartz
Copy link
Contributor

I will say that I've essentially never actually wanted a module to open a local filesystem file in a web browser. I've wanted a module to open a local filesystem file in "the default application handler, like xdg-open but portable to non Linux operating systems" all the time though.

Unsure what, if anything, you should derive from that.

@minrk
Copy link
Contributor Author
minrk commented Feb 26, 2025

gio launch and gtk-launch won't exist on all systems.

Yeah, that's handled by the detections already in place. The goal here is to use "launch app by name" where available, which is why it's currently purely additive to what's there already.

If xdg-open supported passing an app for a standard 'open with ...', that would be awesome and the simpler way to go. Apparently someone made xdg-launch, which seems to be exactly this. I wish xdg-open had this, and really hope I'm just missing it somewhere and someone can point me to the xdg command to launch an app by name (or default mime-type) with a URL.

What's the story for supporting KDE?

I'm not very familiar with KDE, but looking at docs, I think this should be:

kfmclient exec URL BROWSER_NAME

but it's unclear from the docs if the current default kfmclient openURL behavior opens in the default browser or default app. If anyone knows the way to spell "open $url with $app" for KDE, I'll add it.

The best way to handle this is actually just to go ahead and implement the Desktop File Specification and parse the Exec= line yourself then directly execute the relevant command.

Would folks prefer that? It is simpler, in a way.

I've wanted a module to open a local filesystem file in "the default application handler, like xdg-open but portable to non Linux operating systems" all the time though.

Yeah, that makes sense as a feature request, and is already at #47427 (opened 17 years ago). But it isn't what the webbrowser module claims to do, so doesn't seem actionable here.

@eli-schwartz
Copy link
Contributor

I'm not very familiar with KDE, but looking at docs, I think this should be:

kfmclient exec URL BROWSER_NAME

but it's unclear from the docs if the current default kfmclient openURL behavior opens in the default browser or default app. If anyone knows the way to spell "open $url with $app" for KDE, I'll add it.

kfmclient is part of the konqueror package and openURL opens the url in Konqueror (a somewhat popular browser in the KDE world). It is no different from hardcoding firefox.

kfmclient exec pops up an empty (unpopulated) dialog asking you to choose an application. Maybe I'm misusing it, since KDE isn't my primary desktop. The box at the top does allow you to type in the name of a program executable to launch with. It's not remembering anything for me either. Note "remember application association" indicates it's in theory supposed to be offering xdg-open compatible mimetype options for "inode/directory" or "text/html"

kfmclient exec file:///tmp
screenshot

kfmclient exec https://example.com
screenshot-https

Note also that xdg-open internally uses kde-open "for recognized versions of KDE" and the fallback for really old KDE versions is... kfmclient exec, in remembrance of the fact that in the long ago, konqueror was available in all KDE sessions.

Yeah, that makes sense as a feature request, and is already at #47427 (opened 17 years ago). But it isn't what the webbrowser module claims to do, so doesn't seem actionable here.

Yeah I know. The point was rather that if I were the one designing a "webbrowser" module from scratch I would simply reject any urls that didn't have a protocol which targets the World Wide Web. :P

I'm biased though.

@minrk
Copy link
Contributor Author
minrk commented Feb 27, 2025

kfmclient exec file:///tmp

Yeah, I don't think we should add any calls to kfmclient exec URL, since that aims to do the same default-opener action as xdg-open. I would only use it in the form that allows specifying explicitly to launch in a browser.

I just did a fresh install of kubuntu 24.04, and observed:

  1. kfmclient is not available, the current implementation is apparently kioclient
  2. kioclient exec file://url without specifying what to launch definitely isn't what we want, as you demonstrated
  3. the what-to-launch apparently wants a url scheme, not an app name, so the right command is kioclient exec file://$PWD/file.html x-scheme-handler/https (i.e. open url X with default handler for mime Y). Advantage: we don't need to lookup the browser name for this to work.
  4. gtk-launch is present and gtk-launch $(xdg-settings get default-web-browser) file://$PWD/file.html does the right thing, so the desired behavior does happen by default with this PR as-is (for kubuntu, at least). I don't know how common that will be.

Re kioclient --commands output:

 kioclient exec 'url' ['mimetype']
            # Tries to open the document pointed to by 'url', in the application
            # associated with it in KDE. You may omit 'mimetype'.
            # In that case the mimetype is determined automatically.
            # 'url' can be the URL of a document, a *.desktop file,
            # or an executable.

I've added kioclient exec {url} x-scheme-handler/https on KDE and support for the gtk4-launch name.

@eli-schwartz
Copy link
Contributor

gtk-launch will be available only if the user happens to have gtk 3.x apps installed. Many users of KDE desktops only have Qt apps installed.

gtk4-launch is similar but for gtk 4.x

You need to check both and you cannot assume either one.

Users using Qt-based window managers or EFL or various minimalist ones in combination with their favorite set of Qt apps but who don't have the KDE Framework installed. xdg-open will still work and still exist albeit it will open https urls in the default webbrowser while violating the webbrowser.open module docs for files, because people mostly assume xdg-utils is all that needs to be portable and broadly available.

You need a fallback for those people and I don't think you will get one unless you implement the Desktop File specification yourself and read the ini files directly.

@minrk
Copy link
Contributor Author
minrk commented Feb 28, 2025

You need to check both and you cannot assume either one.

Yup, that's done here.

You need a fallback for those people

To be clear, the changes here are (almost) purely in addition to what's already there, which is a pretty long try sequence, so all the fallbacks that already exist for that case remain present. I've only added a couple and removed none, so xdg-open remains the top priority if gtk[4]-launch is not found. The only change that's not purely an addition is skipping xdg-open (and a couple similar entries) for file:// URLs, at which point it proceeds through the fairly lengthy fallback chain of about 15 browsers by name.

And all of these remain lower priority than the longstanding behavior of launching the default browser directly if it's found by name (e.g. if default browser is firefox.desktop and firefox is on $PATH). That's all unchanged by this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
awaiting review
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@minrk @eli-schwartz
0