gvfs-open was deprecated in 2015 and removed in 2018, but its replacement,
gio(1), is not available in Ubuntu 16.04, which is apparently still
supported by CPython upstream even though it is considered to be EOL by
Ubuntu developers.
Signed-off-by: Simon McVittie <smcv@debian.org>
* [bpo-43137](): webbrowser: Prefer gio open over gvfs-open
gvfs-open(1) was superseded by gio(1) in 2015, and removed from GNOME
releases in 2018. Debian and its derivatives like Ubuntu currently still
have a compatibility shim for gvfs-open, but we plan to remove it.
webbrowser prefers xdg-settings and xdg-open over gvfs-open, so this
will only have any practical effect on systems where the xdg-utils
package is not installed.
Note that we don't check for GNOME_DESKTOP_SESSION_ID before using gio.
gio does the right thing on any desktop environment that follows
freedesktop.org specifications, similar to xdg-settings, so it's
unnecessary to guard in this way. GNOME_DESKTOP_SESSION_ID was deprecated
in 2008 and removed from upstream gnome-session in 2018 (it's still
present in Debian/Ubuntu for backward compatibility, but probably
shouldn't be). The replacement way to detect a desktop environment is
the XDG_CURRENT_DESKTOP environment variable, which is a colon-separated
sequence where the first item is the current desktop environment and the
second and subsequent items (if present) are other desktop environments
that it resembles or is based on.
Resolves:
* [bpo-43137](): webbrowser: Never invoke gnome-open
gnome-open was part of GNOME 2, which was superseded in around 2010 and
is unmaintained. The replacement was gvfs-open, which was subsequently
replaced by gio(1) (as used in the previous commit).
* [bpo-43137](): webbrowser: Don't run gvfs-open on GNOME
gvfs-open was deprecated in 2015 and removed in 2018. The replacement
is gio(1) (as used in a previous commit).
GNOME_DESKTOP_SESSION_ID was deprecated in 2008 and removed in 2018.
The replacement is XDG_CURRENT_DESKTOP (as mentioned in a previous
commit).
---
To test this on a typical modern Linux system, it is necessary to disable the `xdg-settings` and `xdg-open` code paths, for example with this hack:
<details><summary>Hack to disable use of xdg-settings and xdg-open</summary>
```diff
diff --git a/Lib/webbrowser.py b/Lib/webbrowser.py
index 3244f206aa..8f6c09d1d2 100755
--- a/Lib/webbrowser.py
+++ b/Lib/webbrowser.py
@@ -459,7 +459,7 @@ def open(self, url, new=0, autoraise=True):
def register_X_browsers():
# use xdg-open if around
- if shutil.which("xdg-open"):
+ if 0 and shutil.which("xdg-open"):
register("xdg-open", None, BackgroundBrowser("xdg-open"))
# Opens an appropriate browser for the URL scheme according to
@@ -549,7 +549,7 @@ def register_standard_browsers():
# Prefer X browsers if present
if os.environ.get("DISPLAY") or os.environ.get("WAYLAND_DISPLAY"):
try:
- cmd = "xdg-settings get default-web-browser".split()
+ cmd = "false xdg-settings get default-web-browser".split()
raw_result = subprocess.check_output(cmd, stderr=subprocess.DEVNULL)
result = raw_result.decode().strip()
except (FileNotFoundError, subprocess.CalledProcessError, PermissionError, NotADirectoryError) :
```
</details>
I haven't attempted to assess which of the specific web browsers such as Galeon are still extant, and which ones disappeared years ago. They could almost certainly be cleaned up, but that's beyond the scope of this PR.
Would be nice to backport to python 3.7+. I don't think it's worth the hassle to backport this all the way down to 3.10. But I'll let the maintainers decide.
This is hard to test because the test setup already includes this [environment variable](https://github.com/python/cpython/blob/master/Lib/test/pythoninfo.py#L292)
Let me know if something doesn't match the PR guidelines. This is my first PR in the python source code.
Regression introduced in e3ce695 and 25b804a, where the old parameter
update_tryorder to _synthesize was first ignored, then given the opposite
value in the attempt to fix bpo-31014.
The Opera Browser was using a outdated command line invocation that resulted in an incorrect URL being opened in the browser when requested using the webbrowser module.
* Correct the arguments passed to the Opera Browser when opening a new URL.
When checking for the default X web browser, xdg-settings
may emit messages on stderr if some components (such as
kreadconfig5) are unavailable. These messages aren't of
interest to Python, so we just ignore them.
- Add 'preferred' argument to webbrowser.register
- Use xdg-settings to specify preferred X browser
The first change replaces the existing undocumented tri-state
'try_order' parameter with the documented boolean keyword-only
'preferred' parameter. Setting it to True places the browser at the
front of the list, preferring it as the return to a subsequent get() call.
The second change adds a private `_os_preferred_browser` setting
and then uses that to make the default browser reported by
`xdg-settings` first in the try list when running under X (or
another environment that sets the `DISPLAY` variable).
This avoids the problem where the first entry in the tryorder
queue otherwise defaults to xdg-open, which doesn't support
the "new window" option.
requires them. Disable executable bits and shebang lines in test and
benchmark files in order to prevent using a random system python, and in
source files of modules which don't provide command line interface. Fixed
shebang lines in the unittestgui and checkpip scripts.
requires them. Disable executable bits and shebang lines in test and
benchmark files in order to prevent using a random system python, and in
source files of modules which don't provide command line interface. Fixed
shebang line to use python3 executable in the unittestgui script.
This eliminates a ResourceWarning, since before webbrowser was
explicitly opening os.devnull and then leaving it open. Tests
to follow.
Patch by Anton Barkovsky.
Patch by Anton Barkovsky, comment addition by me.
This shows up as a bug in 3.3 because the definition for Chrome
produces such an empty string. Tests will follow.
Patch by Anton Barkovsky, comment addition by me.
This showed up as a bug in 3.3 because the definition for Chrome
produced such an empty string. This fix is tested in 3.3+;
backporting the new test suite is more trouble than it is worth.
