Repository navigation
webbrowser.py triggers unwanted XQuartz startup #87277
Description
| BPO | 43111 |
|---|---|
| Nosy | @terryjreedy, @ronaldoussoren, @ned-deily |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2021-02-03.09:21:34.337>
labels = ['OS-mac', '3.8', '3.9', '3.10', 'performance', 'library']
title = 'webbrowser.py triggers unwanted XQuartz startup'
updated_at = <Date 2021-02-08.09:04:26.632>
user = 'https://bugs.python.org/hans-meine'bugs.python.org fields:
activity = <Date 2021-02-08.09:04:26.632>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'macOS']
creation = <Date 2021-02-03.09:21:34.337>
creator = 'hans-meine'
dependencies = []
files = []
hgrepos = []
issue_num = 43111
keywords = ['patch']
message_count = 6.0
messages = ['386182', '386553', '386555', '386557', '386623', '386625']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'ronaldoussoren', 'ned.deily', 'hans-meine']
pr_nums = ['24480']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'resource usage'
url = 'https://bugs.python.org/issue43111'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']
Activity
hans-meine commentedon Feb 3, 2021
For a long time, I wondered why opening Jupyter notebooks through nbopen always led to XQuartz starting. Now, I found the reason: nbopen uses webbrowser.py to open a web page, and webbrowser.py sees the
DISPLAYvariable being set and calls xdg-settings (which I installed via the xdg-utils port / MacPorts).Apparently, in order to be able to fire up XQuartz on demand and to allow people starting X11 applications,
DISPLAYis set to a string like/private/tmp/com.apple.launchd.<somecode>/org.xquartz:0.I am using Safari and find this starting of XQuartz undesirable (causes a delay, uses system resources, leads to a new running program in the Dock / task switcher). On the other hand I can totally understand that the code makes sense.
As a workaround, I can unset DISPLAY, or uninstall xdg-utils (although it is useful, and may be a dependency of other ports), but I thought I should also bring it up here for discussion.
terryjreedy commentedon Feb 6, 2021
3.7 is a few years old and only gets security fixes. Can you either test on current releases or whether code is still same?
ronaldoussoren commentedon Feb 6, 2021
The same code is present in trunk.
I'm in favour of disabling usage of X11 browsers of macOS, that's almost certainly not what users want.
I no longer have XQuartz installed on my machine, but when I did I only used it for running X11 GUIs on remote Linux systems.
What I'm not entirely sure about: is this something we should back port or just apply to the trunk (3.10)? This is a behaviour change and as such I'd be inclined to only apply to trunk.
hans-meine commentedon Feb 6, 2021
I was trying to be very honest, because I am still running 3.7 for production. However, I have carefully checked and the webbrowser.py has only seen (clearly) unrelated changes.
ronaldoussoren commentedon Feb 8, 2021
I've created a PR for this.
Open question: Is this a bug fix (with back ports to 3.9 and 3.8) or a feature (no back ports)?
terryjreedy commentedon Feb 8, 2021
webbrowser is 'generous' at to what browsers it will open, some of which are not what hardly anyone would want. So I would call this an 'enhancement' (really 'disenchantment', like all removals;-) unless there were a technical reason other than those given for the exclusion.
iritkatriel commentedon Sep 9, 2022
I've updated the version labels. The code change has not been applied to main yet (but I don't know whether it is still needed).
ronaldoussoren commentedon Dec 20, 2023
I'm reviving the PR and will treat this as a new feature, that is I won't perform a back port of the PR. Primary reason for that is that using XQuartz in first place is a niche use case.
gh-87277: Don't look for X11 browsers on macOS in webbrowser (#24480)
ronaldoussoren commentedon Dec 21, 2023
I've merged a fix for this in the main branch.
I'm not backporting this because X11 usage on macOS should be extremely niche these days, but am willing to reconsider.
pythongh-87277: Don't look for X11 browsers on macOS in webbrowser (p…
pythongh-87277: Don't look for X11 browsers on macOS in webbrowser (p…
pythongh-87277: Don't look for X11 browsers on macOS in webbrowser (p…
pythongh-87277: Don't look for X11 browsers on macOS in webbrowser (p…