webbrowser.register incorrectly prefers wrong browser if its name is a substring of `xdg-settings get default-web-browser` result

[guss77]

Bug report

Checklist

• I am confident this is a bug in CPython, not a bug in a third-party project
• I have searched the CPython issue tracker,
  and am confident this bug has not been reported before

CPython versions tested on:

3.11

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

Python 3.11.4 (main, Jun 9 2023, 07:59:55) [GCC 12.3.0]

A clear and concise description of the bug:

I'm using a custom desktop entry (Linux application launcher) that starts Google Chrome with my custom data dir (or any other setting that is relevant). The custom desktop entry is called google-chrome-work.desktop (I have a few other Google Chrome custom launchers for other cases where I need the data dir separated), and this is set as the default browser in the operating system:

$ xdg-settings get default-web-browser
google-chrome-work.desktop

When using the webbrowser to open a URL, without first registering any specific browser, it calls register_standard_browsers() and that in turn runs xdg-settings get default-web-browser, and if that succeeds - sets up the resulting string (which is expected to be a .desktop entry) in _os_preferred_browser. After that register_X_browsers() gets run which knows about a bunch of browsers one might expect to find on Unix systems and tries to register each found with a call to register(). The first such "browser" to be registered is xdg-open - which will automatically use the system preferred web browser (using the XDG spec, that was consulted earlier), and one can always expect to find when xdg-settings is available (both are part of the same spec and always come from the same software package).

All this is great. The problem is that register() wants to check if the registered browser is supposedly the _os_preferred_browser and uses sub string comparison to check that: name in _os_preferred_browser. In my case - because the text "google-chrome" (which is a browser name that register_X_browsers() knows) is a substring of google-chrome-work.desktop - it chooses to have the bare command for Google Chrome as the preferred browser, even though this is definitely not what is needed.

I've looked at the code, and _os_preferred_browser is only used to handle the result of xdg-settings get default-web-browser, so this substring search makes no sense - if _os_preferred_browser is set and has a value - it is guaranteed that using xdg-open is the correct command - we have basically verified that we have a valid FreeDesktop.org default browser configuration so using it is the only thing that is compatible with the FreeDesktop.org specifications (theoretically, we should execute the desktop entry file directly, but that is a lot more complicated and calling xdg-open with an HTTP URL will do the Right Thing™️).

This issue should be fixed by:

1. Removing the substring search - it makes no sense.
2. Make sure to register "xdg-open" (here) in a way that is set as the preferred browser if _os_preferred_browser is set, for example:

    if shutil.which("xdg-open"):
        register("xdg-open", None, BackgroundBrowser("xdg-open"), _os_preferred_browser is not None)

I can offer a PR if this seems reasonable.

Linked PRs

• gh-108172: do not override OS preferred browser if it is a super-string of a known browser #113011
• [3.13] gh-108172: do not override OS preferred browser if it is a super-string of a known browser (GH-113011) #123527
• [3.12] gh-108172: do not override OS preferred browser if it is a super-string of a known browser (GH-113011) #123528

[gpshead]

Thanks. I don't think we have many people that dive into how this code works. Your analysis in the issue here was a useful explanation.

Adding xdg-open as a browser as in your second bullet could make sense if you want to make a PR doing that. I wouldn't backport that one as a bug fix though as I did with the existing merged one. :) (feel free to reopen+reuse this issue if you do make a PR for that)