You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
webbrowser default browser detection and/or public API for _trylist. #68429
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='https://github.com/ncoghlan'closed_at=<Date2017-02-25.08:15:11.057>created_at=<Date2015-05-19.13:43:02.029>labels= ['type-feature']
title='webbrowser default browser detection and/or public API for _trylist.'updated_at=<Date2018-05-30.12:37:14.406>user='https://github.com/davesteele'
When calling webbrowser.open*(), the module goes through a list of installed browsers, and uses the first one that succeeds, to process the request.
The first 'browsers' in the 'X' list are 'xdg-open' and others of that ilk. The problem is that they only have one 'open' behavior - the 'new' parameter is ignored ('same window', 'new window', 'new tab').
I can get the fully supported default browser in GNOME with e.g.
changed the title [-]webbrowser (very often) doesn't support the 'new' parameter[/-][+]webbrowser default browser detection and/or public API for _trylist.[/+]on May 19, 2015
My preferred solution would be a bit intrusive - check for and use
xdg-settings or gi.repository.Gio to identify the default browser, and
match the result against the type list. I'm not sure that would get
approval, nor am I sure of the best standard-library-compliant way to
go about it.
davesteele commented on Jul 18, 2015
davesteelemannequin
MannequinAuthor
More actions
Patch attached, to sort the desktop default browser to the top of _tryorder.
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.
============
After merging this, I belatedly realised that codecov's complaint about the lack of code coverage for the diff was actually valid: now that "preferred" is a public API, it should have a cross-platform test case.
That should be a fairly straightforward test to write, as it can just use an arbitrary string, and then poke around in _tryorder directly to make sure it is updated as expected - it doesn't need to use a valid browser reference.
Activity
davesteele commentedon May 19, 2015
When calling webbrowser.open*(), the module goes through a list of installed browsers, and uses the first one that succeeds, to process the request.
The first 'browsers' in the 'X' list are 'xdg-open' and others of that ilk. The problem is that they only have one 'open' behavior - the 'new' parameter is ignored ('same window', 'new window', 'new tab').
I can get the fully supported default browser in GNOME with e.g.
... but this code accesses a private list.
The problems are:
webbrowser does not determine and return the current default browser.
There is no public interface for determining the current/installed browser type list.
The problem can be mitigated by resolving (1) and/or (2).
Also, the browser type list in the documentation is missing many entries.
Checked on 2.7 and 3.4. I believe this is valid across all supported versions.
bitdancer commentedon May 19, 2015
Any change is going to be an enhancement, so it will only go in 3.6 (at this point...beta/feature freeze for 3.5 is this weekend).
Would you like to propose a patch?
[-]webbrowser (very often) doesn't support the 'new' parameter[/-][+]webbrowser default browser detection and/or public API for _trylist.[/+]davesteele commentedon May 19, 2015
On Tue, May 19, 2015 at 10:19 AM, R. David Murray
<report@bugs.python.org> wrote:
...
My preferred solution would be a bit intrusive - check for and use
xdg-settings or gi.repository.Gio to identify the default browser, and
match the result against the type list. I'm not sure that would get
approval, nor am I sure of the best standard-library-compliant way to
go about it.
davesteele commentedon Jul 18, 2015
Patch attached, to sort the desktop default browser to the top of _tryorder.
davesteele commentedon Feb 14, 2017
See #85
ultimatecoder commentedon Feb 18, 2017
Hello David,
I hope you are still working on #85 I tried to add few suggestions. Please write back on any confusions. Thanks!
davesteele commentedon Feb 18, 2017
Jaysinh,
Thanks for the feedback. I'm adding the documentation now.
As I noted in github, I'm not sure what the preferred exception handling would be for xdg-settings.
ncoghlan commentedon Feb 25, 2017
To summarise the changes that were made during the PR review, here's the eventual commit message for the merged PR:
============
bpo-24241: Improve preferred webbrowser handling (#85)
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_browsersettingand then uses that to make the default browser reported by
xdg-settingsfirst in the try list when running under X (oranother environment that sets the
DISPLAYvariable).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.
============
ncoghlan commentedon Feb 25, 2017
After merging this, I belatedly realised that codecov's complaint about the lack of code coverage for the diff was actually valid: now that "preferred" is a public API, it should have a cross-platform test case.
That should be a fairly straightforward test to write, as it can just use an arbitrary string, and then poke around in _tryorder directly to make sure it is updated as expected - it doesn't need to use a valid browser reference.
ncoghlan commentedon Feb 25, 2017
Second PR merged with the missing test case.
berkerpeksag commentedon Mar 24, 2017
New changeset 370f7a9 by Berker Peksag in branch 'master':
bpo-24241: Add versionchanged directive to the documentation (#342)
370f7a9
ncoghlan commentedon Mar 24, 2017
New changeset 56a8ecc by Nick Coghlan in branch 'master':
bpo-24241: Add dedicated webbrowser.register test case (#288)
56a8ecc
ncoghlan commentedon Mar 24, 2017
New changeset e3ce695 by Nick Coghlan (David Steele) in branch 'master':
bpo-24241: Improve preferred webbrowser handling (#85)
e3ce695
vstinner commentedon May 30, 2018
It seems like this issue introduced a regression: bpo-33693.