Created on 2015-05-19 13:43 by daves, last changed 2018-05-30 12:37 by berker.peksag. This issue is now closed.
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.
def browser():
app = Gio.app_info_get_default_for_type('x-scheme-handler/https', True)
bpath = app.get_filename()
for candidate in webbrowser._tryorder:
if candidate in bpath:
return webbrowser.get(using=candidate)
return webbrowser.get()
... but this code accesses a private list.
The problems are:
1) webbrowser does not determine and return the current default browser.
2) 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.
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?
On Tue, May 19, 2015 at 10:19 AM, R. David Murray
<report@bugs.python.org> wrote:
...
> Would you like to propose a patch?
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.
Patch attached, to sort the desktop default browser to the top of _tryorder.
See
Hello David,
I hope you are still working on I tried to add few suggestions. Please write back on any confusions. Thanks!
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.
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)
- 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.
============
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.
Second PR merged with the missing test case.
New changeset 370f7a956cef5895c93ca5a53fc26b04df973aaf by Berker Peksag in branch 'master':
bpo-24241: Add versionchanged directive to the documentation (#342)
New changeset 56a8eccc43c66ae51c5a6bfc89635b1998fd419e by Nick Coghlan in branch 'master':
bpo-24241: Add dedicated webbrowser.register test case (#288)
New changeset e3ce69522ffd7c0354d6e70d18f42bce325ed97e by Nick Coghlan (David Steele) in branch 'master':
bpo-24241: Improve preferred webbrowser handling (#85)
It seems like this issue introduced a regression: bpo-33693.