bpo-43137: webbrowser: Replace gvfs-open and gnome-open with "gio open"

[smcv]

• 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: https://bugs.python.org/issue43137

• 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:

Hack to disable use of xdg-settings and xdg-open

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) :

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.

https://bugs.python.org/issue43137

Automerge-Triggered-By: GH:jaraco

[FFY00]

Thank you! This looks correct and makes the code more portable. I agree with the scope.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[FFY00]

@jaraco could you have a look?

[jaraco]

• 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.

From a user's perspective, what's the preferred behavior? Is it possible/desirable to give gio-open precedence?

[jaraco]

I looked at the tests and don't see anything relevant for these code paths, so following the pattern of the predecessors seems fine.

[smcv]

From a user's perspective, what's the preferred behavior? Is it possible/desirable to give gio-open precedence?

On GNOME, and any other desktop environment that relies on freedesktop.org specifications, there should be little or no practical difference. The GNOME code path in xdg-open uses gio open, and gio open uses the same freedesktop.org configuration/integration stuff as xdg-settings.

For some non-GNOME desktops, there are legacy code paths in xdg-open (and I think xdg-settings) which might use desktop-specific configuration instead of the freedesktop.org specifications. I would hope that all Unix desktop environments standardized on freedesktop.org mechanisms several years ago (like GNOME did, and I think KDE too) but there might be a few that are stuck in the past.

gio open will be somewhat more efficient than xdg-open, because it's C code with a single execution flow, rather than a large shell script with various legacy code paths (although realistically nobody is likely to notice a performance difference). The down side of gio open is that if you were expecting one of those legacy code paths to be entered, you will be disappointed.

[smcv]

to give gio-open precedence

Note that there is no gio-open command, only gio, which has several git-style subcommands: the one I use here is gio open, which is the equivalent of the old gvfs-open and gnome-open.

[jaraco]

It sounds as if the implications of giving gio precedence may be preferable but might introduce unexpected behaviors. My inclination would be to give it precedence now while the library is in alpha, and if there are problems, it can be corrected in a bugfix. Would you explore that possibility?

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[smcv]

It sounds as if the implications of giving gio precedence may be preferable but might introduce unexpected behaviors. My inclination would be to give it precedence now while the library is in alpha, and if there are problems, it can be corrected in a bugfix. Would you explore that possibility?

If a Python developer wants to go further than what I've done in this branch, of course that's absolutely fine, but as an outsider I'm not particularly keen to be responsible for changes that I am not personally sure about, particularly knowing that I will not necessarily be available immediately to respond to any regressions that might occur.

Making gio open higher-precedence than xdg-open would be technically straightforward (swap two blocks) and I can add a commit to do that if you want. However, the advantage of doing gio open before xdg-open is fairly small (use less shell script, avoid legacy code paths) and it could result in launching the "wrong" web browser on some desktop environments (if their users expect the legacy code paths to be used), so it is perhaps not such a great tradeoff.

Looking at xdg-open, it seems that XFCE has a non-freedesktop.org web browser configuration mechanism, which is entangled with fd.o web browser handling for compatibility but not really entirely integrated with it; so XFCE (which I don't use) is an environment that is somewhat more likely to regress.

It isn't immediately obvious to me how to make gio open higher-precedence than xdg-settings, and looking at the commit history, I think doing that would reintroduce https://bugs.python.org/issue24241.

[jaraco]

Sounds good. Appreciate the clarity in rationale.

[tiran]

I think this changeset causes a regression. gio is not available in old distros like Ubuntu Xenial.

[jaraco]

Thanks tiran. It's my understanding that Xenial (16.04) went EOL earlier this year. Does Python 3.11 to be released in 2022 need to support environments that went EOL this year? If so, when would Python be able to drop this support?

@smcv Would it be possible to support gio open over gvfs-open and gnome-open without dropping support for the legacy mechanism?

[smcv]

@smcv Would it be possible to support gio open over gvfs-open and gnome-open without dropping support for the legacy mechanism?

Sure, just revert aed1ba5 (and optionally 251ea9c, but nobody should be using gnome-open in 2021, never mind 2022).

[tiran]

but nobody should be using gnome-open in 2021, never mind 2022).

You would be surprised how many people complain when latest Python breaks on their ancient distro or hardware. :)

[smcv]

Sure, just revert aed1ba5 (and optionally 251ea9c, but nobody should be using gnome-open in 2021, never mind 2022).

#30417 reverts aed1ba5, if that's what you want.