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.

What is the right way to do it then? It should also remain compatible with Firefox < 36.

Details: https://bugzilla.mozilla.org/show_bug.cgi?id=1080319

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.)

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.

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.)

> 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?

WinPdb = Windowed Pdb, not MS Windows Pdb.

`sudo apt-get install winpdb`

Oops, sorry. The best way forward would be for you to investigate and find out why xdg-open isn't preferred in your setting.

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.)

I created the attached module to work with new FF in Python 2.7. You can convert it to proper patch for webbrowser.py.

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).

--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

> this will break the support of IceApe on Debian Etch

Is Python committed to supporting obsolete Debian releases? The latest oldstable Debian release (6.0 Squeeze) has iceape-2.0.11 [1], which does seem to support the -new-window and -new-tab options (I haven't actually tested this, though - I just looked at the source code [2]).

The iceweasel/iceape products are just rebranded versions of Firefox and Seamonkey. The webbrowser module currently supports them via the generic Mozilla class - so Python should only be concerned about which versions of the common Mozilla codebase it needs to continue support for.

[1] https://packages.debian.org/search?suite=squeeze&searchon=names&keywords=iceape
[2] http://anonscm.debian.org/cgit/pkg-mozilla/iceape.git/tree/mozilla/browser/components/nsBrowserContentHandler.js?h=squeeze#n419

May it is time to drop support of SeaMonkey 1.x and systems released 8 years ago. But then we should drop the support of browsers "netsape", "mozilla", "firebird". And this should be documented somewhere.

Patch for Python 2.7 to support Firefox >= 36.0, with version test.

Patch for Python 3.4 and 3.5 to support Firefox >= 36.0, with version test.

Thanks for the patches! Can't you just use a function from the high level subprocess API (like subprocess.run()?

Not subprocess.run() as I'm aiming to Python 2.7. Perhaps subprocess.check_output(). I'll try it.

Updated patch for Python 2.7 with subprocess.check_output().

Updated patch for Python 3.4+ with subprocess.check_output().

I was talking about webbrowser.py-3.4-newfox.patch

3.4 is now in security-fix-only mode so we can't push the patch to the 3.4 branch.

I am on Debian 8 "jessie" that only has Python 3.4, so I want to patch webbrowser.py in a backward-compatible way.

Add NewFox class to webbrowser for Py 2.7 (added raise_opts — Mozilla no longer supports autoraise).

Add NewFox class to webbrowser for Py 3.4 (added raise_opts — Mozilla no longer supports autoraise).

Remove empty args (backported from 3.4).

Would not be easier to drop a support of SeaMonkey 1.x and other ancient browsers?

I don't think Firefox versions <36 are too old to be dropped.

> I don't think Firefox versions <36 are too old to be dropped.

Just Firefox versions <1.5.

Firefox 1.5 released 11 years ago supported options -new-window and -new-tab [1].

[1] http://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-US/firefox/releases/1.5.html

Ah, I see. Ok then, see the new patch.

Tests are failed with webbrowser.py-3.5-newfox.patch.

What's the error? Buildbot URL?

$ ./python -m test.regrtest -vuall test_webbrowser
...
======================================================================
FAIL: test_open (test.test_webbrowser.MozillaCommandTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.5/Lib/test/test_webbrowser.py", line 99, in test_open
    arguments=['openURL({})'.format(URL)])
  File "/home/serhiy/py/cpython-3.5/Lib/test/test_webbrowser.py", line 42, in _test
    self.assertIn(option, popen_args)
AssertionError: '-raise' not found in ['http://www.example.com']

Oops, yes, mea culpa, sorry. Patch for the test added.

Could you please provide a patch including all changes in unified format?

Done.

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?

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.

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.

Then I don't have any objections. But I also couldn't test the change — I only use Firefox (and sometimes Chrome).

New changeset dacb52577c1c by Serhiy Storchaka in branch '3.5':
Issue #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':
- Issue #23262: The webbrowser module now supports Firefox 36+ and derived
https://hg.python.org/cpython/rev/f1abc92a756a

New changeset cade42bd0ee0 by Serhiy Storchaka in branch 'default':
Issue #23262: The webbrowser module now supports Firefox 36+ and derived
https://hg.python.org/cpython/rev/cade42bd0ee0

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).

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.

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.

> I'm not sure that we can break the compatibility with old browser

I agree with this.

Processo webbrowser.3.5-2.patch

I think this six year old issue can be closed. All patches for 3.x are committed, and Python 2.7 is EOL.