-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
webbrowser.register incorrectly prefers wrong browser if its name is a substring of xdg-settings get default-web-browser
result
#108172
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.
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
Comments
When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox".
When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox".
When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox".
When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox".
When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox".
When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox".
…ng of a known browser (GH-113011) When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox". #108172 explains in more detail, and lays out a potential better future enhancement for this case of just using xdg-open. We'll go with this for now. --------- Co-authored-by: Alex Waygood <[email protected]>
…r-string of a known browser (pythonGH-113011) When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox". python#108172 explains in more detail, and lays out a potential better future enhancement for this case of just using xdg-open. We'll go with this for now. --------- (cherry picked from commit 10bf615) Co-authored-by: Oded Arbel <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
…r-string of a known browser (pythonGH-113011) When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox". python#108172 explains in more detail, and lays out a potential better future enhancement for this case of just using xdg-open. We'll go with this for now. --------- (cherry picked from commit 10bf615) Co-authored-by: Oded Arbel <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
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) |
…er-string of a known browser (GH-113011) (GH-123528) gh-108172: do not override OS preferred browser if it is a super-string of a known browser (GH-113011) When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox". #108172 explains in more detail, and lays out a potential better future enhancement for this case of just using xdg-open. We'll go with this for now. --------- (cherry picked from commit 10bf615) Co-authored-by: Oded Arbel <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
…er-string of a known browser (GH-113011) (GH-123528) gh-108172: do not override OS preferred browser if it is a super-string of a known browser (GH-113011) When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox". python/cpython#108172 explains in more detail, and lays out a potential better future enhancement for this case of just using xdg-open. We'll go with this for now. --------- (cherry picked from commit 10bf615bab9f832971a098f0a42b0d617aea6993) Co-authored-by: Oded Arbel <[email protected]> Co-authored-by: Alex Waygood <[email protected]> CPython-sync-commit-latest: bf9981830393edf9cc91003a5f89de15d66d0f2f
Thanks. I'll see about doing this later (not soon, life happened and stuff). |
…er-string of a known browser (GH-113011) (#123527) gh-108172: do not override OS preferred browser if it is a super-string of a known browser (GH-113011) When checking if the registering browser is the "OS preferred browser", do not use a substring search - that makes no sense: one can have a preferred browser that looks like a super-string of a known browser, e.g. "firefox-nightly" vs "firefox". #108172 explains in more detail, and lays out a potential better future enhancement for this case of just using xdg-open. We'll go with this for now. --------- (cherry picked from commit 10bf615) Co-authored-by: Oded Arbel <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Checklist
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:When using the
webbrowser
to open a URL, without first registering any specific browser, it callsregister_standard_browsers()
and that in turn runsxdg-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 thatregister_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 toregister()
. The first such "browser" to be registered isxdg-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 whenxdg-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 thatregister_X_browsers()
knows) is a substring ofgoogle-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 ofxdg-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 usingxdg-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 callingxdg-open
with an HTTP URL will do the Right Thing™️).This issue should be fixed by:
_os_preferred_browser
is set, for example:I can offer a PR if this seems reasonable.
Linked PRs
The text was updated successfully, but these errors were encountered: