GeezerVison is showing github.com — webbrowser module broken with Firefox 36+ · Issue #67451 · python/cpython
webbrowser module broken with Firefox 36+ #67451Description
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'] Activityssokolow commented on Jan 18, 2015 MannequinAuthor More actions pitrou commented on Jan 18, 2015 What is the right way to do it then? It should also remain compatible with Firefox < 36. serhiy-storchaka commented on Jan 18, 2015 ssokolow commented on Jan 18, 2015 MannequinAuthor More actions The proper solution is to prefer start (Windows), open (OSX), or xdg-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 commented on 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 commented on Jan 18, 2015 MannequinAuthor More actions 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:
if os.name == 'posix' and not platform.mac_ver()[0]:
with open(os.devnull, 'wb') as nul:
subprocess.Popen(['xdg-open', request_url], stdout=nul, stderr=nul)
else:
webbrowser.open_new_tab(request_url)(This retrofit branch hasn't yet reached the point where it'll be tested on Windows. I may still add another branch which calls start directly if it proves to have the same priority bug on Windows.) pitrou commented on 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.
You have xdg-open under Windows? ssokolow commented on Jan 18, 2015 MannequinAuthor More actions WinPdb = Windowed Pdb, not MS Windows Pdb. sudo apt-get install winpdb
pitrou commented on 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 commented on Jan 18, 2015 MannequinAuthor More actions 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 commented on 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 commented on 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 commented on Feb 27, 2015 serhiy-storchaka commented on 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 commented on 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 commented on 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 commented on 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 commented on Oct 30, 2016 serhiy-storchaka commented on 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 commented on 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 commented on 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 commented on Nov 6, 2016
I'm not sure that we can break the compatibility with old browser
I agree with this. Syaifulnizamshamsudin commented on Oct 10, 2021 Syaifulnizamshamsudinmannequin Processo webbrowser.3.5-2.patch wyz23x2 commented on 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.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|