Repository navigation
webbrowser module broken with Firefox 36+ #67451
Copy link
Copy link
Closed
Labels
3.7 (EOL)end of lifeend of lifestdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
| BPO | 23262 |
|---|---|
| Nosy | @phdru, @ssokolow, @ezio-melotti, @lilydjwg, @berkerpeksag, @serhiy-storchaka, @wyz23x2, @Syaifulnizamshamsudin |
| Files |
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 = <Date 2021-10-12.14:20:03.194>
created_at = <Date 2015-01-18.04:16:56.445>
labels = ['3.7', 'type-bug', 'library']
title = 'webbrowser module broken with Firefox 36+'
updated_at = <Date 2021-10-12.14:20:03.192>
user = 'https://github.com/ssokolow'bugs.python.org fields:
activity = <Date 2021-10-12.14:20:03.192>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2021-10-12.14:20:03.194>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2015-01-18.04:16:56.445>
creator = 'ssokolow'
dependencies = []
files = ['45228', '45236', '45237']
hgrepos = []
issue_num = 23262
keywords = ['patch']
message_count = 47.0
messages = ['234218', '234248', '234256', '234284', '234285', '234289', '234290', '234291', '234292', '234293', '236529', '236727', '236737', '236826', '236838', '270554', '270555', '270556', '270563', '270565', '270566', '270567', '270569', '278340', '278341', '278346', '279381', '279384', '279390', '279392', '279399', '279400', '279403', '279407', '279491', '279492', '279529', '279541', '279544', '279545', '279735', '279766', '279767', '279989', '280130', '403574', '403731']
nosy_count = 10.0
nosy_names = ['phd', 'bazwal', 'ssokolow', 'ezio.melotti', 'python-dev', 'lilydjwg', 'berker.peksag', 'serhiy.storchaka', 'wyz23x2', 'Syaifulnizam']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue23262'
versions = ['Python 3.5', 'Python 3.6', 'Python 3.7']Metadata
Metadata
Assignees
Labels
3.7 (EOL)end of lifeend of lifestdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Activity
ssokolow commentedon Jan 18, 2015
As of Firefox 36 (currently in beta channel), the -remote option has been removed.
https://www.mozilla.org/en-US/firefox/36.0a2/auroranotes/
https://www.mozilla.org/en-US/firefox/36.0beta/releasenotes/
As such, attempting to open http://www.example.com/ using webbrowser.open() or webbrowser.open_new_tab() results in "File not Found" tabs pointing to these two URLs, respectively:
file:///home/ssokolow/openURL%28http://www.example.com/%29
file:///home/ssokolow/openURL%28http://www.example.com/,new-tab%29
As I happen to have the Dead Snakes PPA set up on Lubuntu 14.04 for use with tox, I was able to confirm this as an issue in Python 2.7, 3.1, 3.2, 3.3, and 3.4.
pitrou commentedon Jan 18, 2015
What is the right way to do it then? It should also remain compatible with Firefox < 36.
serhiy-storchaka commentedon Jan 18, 2015
Details: https://bugzilla.mozilla.org/show_bug.cgi?id=1080319
ssokolow commentedon Jan 18, 2015
The proper solution is to prefer
start(Windows),open(OSX), orxdg-open(everything else... usually but not always present) when present instead of calling the browser directly.That way, you're using the same "delegate to the desktop's associations system and let the user's preferences control new window vs. new tab" behaviour on all OSes where it's reliably possible.
(Yes, it would guarantee that all open* functions are equivalent, but that's already the norm in a lot of cases... especially with Firefox where one of the guiding design principles is ensuring that the user retains control of their browsing experience.)
pitrou commentedon Jan 18, 2015
That doesn't really answer the question. The webbrowser module is already able to use "xdg-open" (though not "open"), but it has a fallback on various concrete browsers (including Firefox) in case xdg-open doesn't work / doesn't exist.
ssokolow commentedon Jan 18, 2015
Well, then the code which chooses a backend is broken because I have xdg-open and, according to WinPdb, it's using the Mozilla backend.
This was my local workaround:
(This retrofit branch hasn't yet reached the point where it'll be tested on Windows. I may still add another branch which calls
startdirectly if it proves to have the same priority bug on Windows.)pitrou commentedon Jan 18, 2015
You have xdg-open under Windows?
ssokolow commentedon Jan 18, 2015
sudo apt-get install winpdbpitrou commentedon Jan 18, 2015
Oops, sorry. The best way forward would be for you to investigate and find out why xdg-open isn't preferred in your setting.
ssokolow commentedon Jan 18, 2015
Noted. I'm not sure what my schedule will be like, but I'll try.
(I may get back to you with an answer later today or I may not within the week.)
phdru commentedon Feb 24, 2015
I created the attached module to work with new FF in Python 2.7. You can convert it to proper patch for webbrowser.py.
bazwal commentedon Feb 27, 2015
I arrived at an almost identical solution to the one given by Oleg. It works for me with FF 28, 35 & 36 - but presumably there are earlier versions where it does not, otherise why have the -remote option at all?
The gist of the Mozilla bug report is that the option has existed for a very long time, but there are now other command-line options that do exactly the same thing. So the only question seems to be whether Python should still support those older versions of FF that actually require it (if any exist).
On the xdg-open issue: the $BROWSER env var has priority over the default list of browsers to try, so that might explain why xdg-open is not being used on some systems (that is how I originally became aware of this problem).
serhiy-storchaka commentedon Feb 27, 2015
--new-window and --new-tab are Firefox and SeaMonkey2.x only. [1] So this will break the support of IceApe on Debian Etch (iceape v.1.0.13 [2]).
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options
[2] http://archive.debian.net/etch/devel/iceape
24 remaining items
serhiy-storchaka commentedon Oct 27, 2016
The problem is that this class is used for Netscape and old Mozilla browsers. What if rename old Mozilla class to Netscape and use it for old browsers?
phdru commentedon Oct 27, 2016
I'd rather rename the new class to something like Firefox. So there will be 3 classes — Netscape, Mozilla and Firefox. Firefox only for firefox executable.
serhiy-storchaka commentedon Oct 27, 2016
Currently Netscape is just an alias to Mozilla. Since SeaMonkey is synchronized with Firefox, I suppose it dropped the support of the -remote option at the same time. Debian rebranded Firefox and SeaMonkey at 2006, therefore IceWeasel and IceApe always supported -new-win and -new-tab options. The last IceWeasel version was 38, it didn't supported the -remote option.
phdru commentedon Oct 27, 2016
Then I don't have any objections. But I also couldn't test the change — I only use Firefox (and sometimes Chrome).
python-dev commentedon Oct 30, 2016
New changeset dacb52577c1c by Serhiy Storchaka in branch '3.5':
Issue bpo-23262: The webbrowser module now supports Firefox 36+ and derived
https://hg.python.org/cpython/rev/dacb52577c1c
New changeset f1abc92a756a by Serhiy Storchaka in branch '3.6':
https://hg.python.org/cpython/rev/f1abc92a756a
New changeset cade42bd0ee0 by Serhiy Storchaka in branch 'default':
Issue bpo-23262: The webbrowser module now supports Firefox 36+ and derived
https://hg.python.org/cpython/rev/cade42bd0ee0
serhiy-storchaka commentedon Oct 31, 2016
What to do with 2.7? We can just backport the patch from 3.5, but also can use the version check from earlier Oleg's patches. 2.7 was released long time ago and still can be used on systems with old browsers (however it is very unlikely that Python is updated, but browsers are not).
phdru commentedon Oct 31, 2016
Let's me disagree because Python 2.7 is a very special case. One can easily update a browser — they are perfectly compatible. But one cannot just update Python 2.7 because Python 3 is rather a different language that requires a lot of porting effort. So I can imagine Python 2.7 with new browser on the same computer.
serhiy-storchaka commentedon Nov 3, 2016
I don't understand with what you disagree. I can imagine old Python 2.7 with old browser, old Python 2.7 with new browser, new Python 2.7 with new browser, and even new Python 2.7 with old browser on the same computer (but the latter is very unlikely).
Old Python 2.7 don't work with new browser and we can't do anything with this. We can make new Python 2.7.12 working with new browser. But I'm not sure that we can break the compatibility with old browser that could be installed when Python 2.7 was first installed on the same computer.
phdru commentedon Nov 6, 2016
I agree with this.
Syaifulnizamshamsudin commentedon Oct 10, 2021
Processo webbrowser.3.5-2.patch
wyz23x2 commentedon Oct 12, 2021
I think this six year old issue can be closed. All patches for 3.x are committed, and Python 2.7 is EOL.