Firefox no longer supports -remote parameter

Bug #1425972 reported by David Pottage
214
This bug affects 42 people
Affects Status Importance Assigned to Milestone
Exo
Fix Released
Medium
GNU Emacs
Unknown
Unknown
Mozilla Firefox
Fix Released
Medium
Python
Fix Released
Unknown
emacs24 (Ubuntu)
Fix Released
Medium
Unassigned
Trusty
Won't Fix
Medium
Unassigned
Utopic
Won't Fix
Medium
Unassigned
exo (Debian)
Fix Released
Unknown
exo (Ubuntu)
Fix Released
Medium
Unassigned
Trusty
Fix Released
Medium
Unassigned
Utopic
Won't Fix
Medium
Unassigned
firefox (Ubuntu)
Fix Released
High
Unassigned
Trusty
Fix Released
High
Unassigned
Utopic
Fix Released
High
Unassigned

Bug Description

[Impact]
As of Firefox version 36, the -remote commandline parameter was dropped. This parameter is used in versions of exo prior to 0.10.3. Because of this, opening any URLs via exo-open will cause a new firefox window to launch at the home screen.

As reported, this affects the terminal, ubuntu-bug, xchat, and numerous other applications.

[Test Case]
1. Set Firefox as the default web browser in "Preferred Applications".
2. From a terminal, type the following:

exo-open "http://www.xfce.org"

Expected: Firefox opens at http://www.xfce.org
Actual: Firefox opens at the home page.

[Regression Potential]
No regressions by this change. This fixes the application call to correctly open URLs.

---

[Original Report]
When I click a link from an email it does not work any more.

Instead of opening the link in a new tab, Firefox opens a new empty window and does not follow the link.

If I change the default browser for my desktop from Firefox to Chrome, then Chrome can open the link fine.

I have started seeing this today since firefox was upgraded from v35 to 36.

My email client is Mozilla thunderbird at the latest stable version.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: firefox 36.0+build2-0ubuntu0.14.10.4
ProcVersionSignature: Ubuntu 3.16.0-31.41-generic 3.16.7-ckt5
Uname: Linux 3.16.0-31-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dpottage 3729 F.... pulseaudio
BuildID: 20150224133805
Channel: Unavailable
CurrentDesktop: XFCE
Date: Thu Feb 26 14:30:41 2015
ForcedLayersAccel: False
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
IncompatibleExtensions:
 English (South Africa) Language Pack - <email address hidden>
 English (GB) Language Pack - <email address hidden>
 Français Language Pack - <email address hidden>
 Deutsch (DE) Language Pack - <email address hidden>
 Default - {972ce4c6-7e08-4474-a285-3208198ce6fd}
InstallationDate: Installed on 2013-07-02 (604 days ago)
InstallationMedia: Xubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423.1)
IpRoute:
 default via 192.168.1.254 dev eth0 proto static
 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.131 metric 1
MostRecentCrashID: bp-86a16931-63d2-435e-8324-421212140304
Plugins:
 Shockwave Flash - /usr/lib/flashplugin-installer/libflashplayer.so
 LibreOffice Plug-in - /usr/lib/libreoffice/program/libnpsoplugin.so (browser-plugin-libreoffice)
 Java(TM) Plug-in 11.25.2 - /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libnpjp2.so
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=36.0/20150224133805 (In use)
RelatedPackageVersions: browser-plugin-libreoffice 1:4.3.3-0ubuntu1
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: yes
  Hard blocked: no
RunningIncompatibleAddons: True
SourcePackage: firefox
SubmittedCrashIDs: bp-86a16931-63d2-435e-8324-421212140304
UpgradeStatus: Upgraded to utopic on 2014-10-29 (119 days ago)
dmi.bios.date: 11/23/2012
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A08
dmi.board.name: 0XR1GT
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA08:bd11/23/2012:svnDellInc.:pnVostro270:pvr:rvnDellInc.:rn0XR1GT:rvrA00:cvnDellInc.:ct3:cvr:
dmi.product.name: Vostro 270
dmi.sys.vendor: Dell Inc.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

The -remote option has existed essentially forever, but I question its usefulness.
- It requires a running instance to be any useful, so any script actually using it should first do -remote 'ping()' and handle the response properly.
- It is not cross-application. The remote service dispatches the -remote commands to the command line handler, and, for example, desktop b2g builds don't have handlers for -remote (although thunderbird and seamonkey do).
- It is not a cross-platform option, which leads to the following point:
- There are other command line ways to do the same thing (at least in Firefox), without having to jump through hoops with -remote 'ping()', because there are command line options to do those same things on non-X11 platforms.

For the latter, in Firefox case:
- -remote 'openURL(url)' can be replaced with firefox url
- -remote 'openURL(url,new-tab)' can be replaced with firefox -new-tab url
- -remote 'openURL(url,new-window)' can be replaced with firefox -new-window url
- -remote 'openfile(file,...)' is the same as -remote 'openurl(file,...) so, can be replaced as above
- -remote 'xfedocommand(openbrowser)' is inherited from the mozilla suite and doesn't make much sense, but can be replaced with firefox -new-window about:home

Thunderbird has:
- openurl
- mailto
- xfedocommand(openinbox)
- xfedocommand(composemessage)

Seamonkey has:
- openurl/openfile
- mailto
- xfedocommand(openbrowser)
- xfedocommand(openinbox)
- xfedocommand(composemessage)

They may not have command line equivalents for all of those, so if they don't, and until they do, we may want to keep the -remote code in toolkit/xre/nsAppRunner.cpp behind a #ifdef for them.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Benjamin, what do you think?

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Mike Hommey [:glandium] from comment #0)
> - -remote 'xfedocommand(openbrowser)' is inherited from the mozilla suite
> and doesn't make much sense, but can be replaced with firefox -new-window
> about:home

firefox -new-window, in fact (without about:home).

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Mike Hommey [:glandium] from comment #0)
> The -remote option has existed essentially forever, but I question its
> usefulness.

*nowadays. Well, since bug 280725, 9 years ago.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

At the same time, we should remove the mozilla-xremote-client binary.

Revision history for this message
In , Neil-httl (neil-httl) wrote :

(In reply to Mike Hommey from comment #0)
> Seamonkey has:
> - openurl/openfile
> - mailto
> - xfedocommand(openbrowser)
> - xfedocommand(openinbox)
> - xfedocommand(composemessage)
>
> They may not have command line equivalents for all of those

-remote openfile(file) -> -file <file>
-remote openurl(url) -> -url <url>
-remote openurl(url,new-window) -> -new-window <url>
-remote openurl(url,new-tab) -> -new-tab <url>
-remote xfedocommand(openbrowser,url) -> -browser <url>
-remote xfedocommand(openinbox) -> -mail
-remote xfedocommand(composemessage,args) -> -compose args

We do have bug 499785 filed on our -remote support... I wonder whether the reporter still uses -remote after all these years.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

I think this is fine. Even if you were using it previously, using new-style remoting is not a big change.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Created attachment 8502937
Remove the -remote option

The -remote option has existed essentially forever, but its usefulness is
questionable:
- It requires a running instance to be any useful, so any script actually
  using it should first do -remote 'ping()' and handle the response properly.
- It is not cross-application. The remote service dispatches the -remote
  commands to the command line handler, and, for example, desktop b2g builds
  don't have handlers for -remote (although thunderbird and seamonkey do).
- It is not a cross-platform option, which leads to the following point:
- There are other command line ways to do the same thing (at least in
  Firefox), without having to jump through hoops with -remote 'ping()',
  because there are command line options to do those same things on non-X11
  platforms.

For the latter, in Firefox case:
- -remote 'openURL(url)' can be replaced with firefox url
- -remote 'openURL(url,new-tab)' can be replaced with firefox -new-tab url
- -remote 'openURL(url,new-window)' can be replaced with firefox -new-window
  url
- -remote 'openfile(file,...)' is the same as -remote 'openurl(file,...) so,
  can be replaced as above
- -remote 'xfedocommand(openbrowser)' is inherited from the mozilla suite and
   doesn't make much sense, but can be replaced with firefox -new-window

The interesting part is that without changing nsBrowserContentHandler.js,
-remote still works, meaning that if people really feel strongly about
-remote, they'll still be able to write an addon to bring it back. This also
means this patch actually doesn't remove -remote for applications other than
Firefox that do support it, although -remote 'ping()' doesn't work as
expected. However, other -remote commands will now work even without a
running instance.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Other applications are free to consider removing the -remote argument handling from their command line handler, but this is out of scope for this bug.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

Comment on attachment 8502937
Remove the -remote option

\o/

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :
Revision history for this message
In , Cbook (cbook) wrote :
Revision history for this message
In , Hub-g (hub-g) wrote :

It seems to be that bug that cause a breakage here.

I have Firefox 32.0.2 installed on Fedora 20. The one in the path.

I run Firefox out m-c that I build myself - directly out of the build tree. So far there was no problem. I could open URL from third-parties app, no problem. Until this morning where I can no longer. It pops up the profile chooser (expected on startup) as it can't find the remote instance.

This is include calling "firefox <URL>"

In short this completely breaks that feature on Linux.

Revision history for this message
In , Hub-g (hub-g) wrote :

Also |./obj-x86_64-unknown-linux-gnu/dist/bin/firefox <URL>| broke too. (this is using the current build)

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Hubert, can you describe precisely what you're doing because I can't reproduce (as in, it works perfectly fine here)

Revision history for this message
In , Hub-g (hub-g) wrote :

Running Firefox from m-i compiled by myself.

|./obj-x86_64-unknown-linux-gnu/dist/bin/firefox|

Then any Gnome app that tries to open a URL tries to open a new instance (I get the profile selector after a while - which is actually longer than when I don't have Firefox running)

If I do in my terminal |firefox URL|, same thing.
If I do in my terminal |./obj-x86_64-unknown-linux-gnu/dist/bin/firefox URL| (from the source dir), same thing.

If every case it used to, before that patch, to open the firefox instance that was running - and this is that patch since I no longer have the problem after reverting it locally.

I run Fedora 20 + Gnome 3.12 in case that matters.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Is your firefox configured to always show the profile selector?

Revision history for this message
In , Hub-g (hub-g) wrote :

yes it is configured to always show it - because I sometime need a different profile (that I start with --no-remote). This is expected when I start a new instance of Firefox.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Hubert Figuiere [:hub] from comment #17)
> yes it is configured to always show it - because I sometime need a different
> profile (that I start with --no-remote). This is expected when I start a new
> instance of Firefox.

even when i configure my firefox to always display the profile selector, I can't reproduce. Can you file a new bug, make it block this one, Cc me, and provide steps to reproduce with builds from the ftp and no pre-existing ~/.mozilla ? (like, run fx32 with -P, create 2 profiles, uncheck box, etc.)

Revision history for this message
In , Kyle Machulis (qdot) wrote :

This broke the browse-url library in emacs, which expects a -remote argument and still uses OpenURL syntax in the browse-url-firefox function.

Not expecting this to be fixed by mozilla, just noting the breakage for further reference.

Revision history for this message
In , Rjesup (rjesup) wrote :

(In reply to Kyle Machulis (OUT OCT 1-NOV 30) [:kmachulis] [:qdot] (USE NEEDINFO?) from comment #19)
> This broke the browse-url library in emacs, which expects a -remote argument
> and still uses OpenURL syntax in the browse-url-firefox function.
>
> Not expecting this to be fixed by mozilla, just noting the breakage for
> further reference.

Ironically, this broke my attempt to follow the link to this bug from Gnus....

Revision history for this message
In , Rjesup (rjesup) wrote :

Ok, some experimentation on Linux:

>For the latter, in Firefox case:
>- -remote 'openURL(url)' can be replaced with firefox url
>- -remote 'openURL(url,new-tab)' can be replaced with firefox -new-tab url

I modified my browse-url function to do this. No Joy. So I tried it from the command line (release FF and locally-built nightly. No Joy.

"./firefox -new-tab http://example.com/" opens the profile selector, always.
Ditto for "./firefox url".
If I select a profile and say "open this one by default", then if I try to use -new-tab I get a bunch of "fcntl(F_SETLK) failed. errno = 11" (no surprise) and then it fails.

firefox.exe -new-tab <whatever> seems to work on Windows

Huh.... So we seem to be horribly broken on linux now. Hopefully this is some odd artifact of my system/env...

Fedora 19, though it likely doesn't matter for the Nightly tests.

Revision history for this message
In , Hub-g (hub-g) wrote :

The problem is regular users upgrading and having the problem. Telling them "clean your profile" isn't a solution.

I'll try to find time to debug this...

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

cf. comment 18.

Revision history for this message
In , Rjesup (rjesup) wrote :

(In reply to Mike Hommey [:glandium] from comment #23)
> cf. comment 18.

I tried a new user with no .mozilla; no easy repro. (Side note: thanks Fedora, I couldn't get back to my main session ("an error has occurred and you will be logged out and all extensions disabled") and lost all my context.) However: that doesn't solve my problem, which is that it doesn't work on my existing profiles. Why? Does this affect others with existing profiles? (likely) Good question, I'm happy to try to help track it down given a hint of where to look.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Unless there are steps to reproduce, I can't say much besides inviting you to debug it yourself, or finding what parts of your existing profiles make it happen.

Revision history for this message
In , Sledru (sledru) wrote :

Added in the release notes with "`-remote` option removed" as wording.

Revision history for this message
In , lilydjwg (lilydjwg) wrote :

How am I supposed to open urls in a specific instance after this change? I mean, what should I use to replace the following:

firefox -P "$1" -remote "openURL($2, new-tab)"

where $1 is the profile name, and $2 is the url.

I sometimes will need different instances of firefox with different configurations, the command above enables me to use FireGuesture to open the current page in another instance, so I don't need copy & paste urls as I do with Google Chrome.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to lilydjwg from comment #27)
> How am I supposed to open urls in a specific instance after this change? I
> mean, what should I use to replace the following:
>
> firefox -P "$1" -remote "openURL($2, new-tab)"
>
> where $1 is the profile name, and $2 is the url.

firefox -P "$1" -new-tab "$2"

Revision history for this message
In , lilydjwg (lilydjwg) wrote :

(In reply to Mike Hommey [:glandium] from comment #28)
> firefox -P "$1" -new-tab "$2"

This doesn't work for me. It always opens in the first instance I've launched.

I'm on Arch Linux and Firefox 36.0b1 just downloaded, commands I used are

./firefox --ProfileManager --new-instance

Then created another profile named "test".

Then I closed it and ran:

./firefox -P default -new-tab URL
./firefox -P test -new-tab URL

All opened in one instance. I used "--ProfileManager --new-instance" to create another instance with test profile, then ran them again. They all opened in the first Firefox window (the default profile one).

Revision history for this message
In , Jmizell (jmizell) wrote :

I can confirm this breaks a similiar use case I have to <email address hidden>. We run a kiosk like environment with two firefox profiles. We need two independent firefox instances that we can launch new windows in, depending on what content is being displayed.

In the past we did this by pinging the window to determine, if a specific instance was active.

  firefox -P profilename -remote 'ping()'

Then either launching a new instances if it wasn't presennt

  firefox -P profilename -new-instance https://www.domain.tld

Or sending the new url to the running instance

  firefox -p profilename -remote "openurl(https://www.domain.tld)"

With the removal of -remote, we have no way of communicating to specific existing Firefox instances. -new-tab and -new-window only open in the first launched instance, we can't direct commands to the second instance of firefox.

Revision history for this message
In , Jypenator (jypenator) wrote :
Revision history for this message
In , Tmp-xfce-34a9950f1e (tmp-xfce-34a9950f1e) wrote :
Revision history for this message
In , Davide Basilio Bartolini (bartolinidb) wrote :

Confirming that removing the -remote option breaks this use case.

I was using firefox profiles with the -remote option to synchronize with KDE activities (one profile per activity) and now I can't open new tabs / windows in the current activity anymore.

firefox -P $profilename -new-tab $url

just ignores the profile name and it opens the tab in the last opened profile

firefox -P $profilename -no-remote -new-tab $url

simply does not open anything, as it complains that firefox is already running.

Please provide a way to open new tabs in a specified profile from the command line!!

(In reply to Jeremy Mizell from comment #30)
> I can confirm this breaks a similiar use case I have to <email address hidden>.
> We run a kiosk like environment with two firefox profiles. We need two
> independent firefox instances that we can launch new windows in, depending
> on what content is being displayed.
>
> In the past we did this by pinging the window to determine, if a specific
> instance was active.
>
> firefox -P profilename -remote 'ping()'
>
> Then either launching a new instances if it wasn't presennt
>
> firefox -P profilename -new-instance https://www.domain.tld
>
> Or sending the new url to the running instance
>
> firefox -p profilename -remote "openurl(https://www.domain.tld)"
>
> With the removal of -remote, we have no way of communicating to specific
> existing Firefox instances. -new-tab and -new-window only open in the first
> launched instance, we can't direct commands to the second instance of
> firefox.

Revision history for this message
In , Christian Hesse (eworm) wrote :

Created attachment 6003
fix helper commands for Firefox 36.0

Firefox 36.0 dropped support for command line argument -remote. This
changes desktop helper file to call firefox with argument -new-tab.

Revision history for this message
In , Evangelos Foutras (foutrelis) wrote :

(In reply to Christian Hesse from comment #1)
> Created attachment 6003 [details]
> fix helper commands for Firefox 36.0
>
> Firefox 36.0 dropped support for command line argument -remote. This
> changes desktop helper file to call firefox with argument -new-tab.

According to the mozilla bug, the equivalent of "-remote 'openURL(url)'" is "firefox url".

We also need to fix the icecat and iceweasel helpers. I'm build those now to see how they behave and if any options are needed.

Revision history for this message
David Pottage (david-electric-spoon) wrote :
Revision history for this message
In , Evangelos Foutras (foutrelis) wrote :

Created attachment 6004
Drop use of the -remote option in Firefox helpers

The attached patch works for me. 'exo-open --launch WebBrowser' opens a new browser window and 'exo-open url' opens the url in a new tab (for all three changed helpers).

Tested browsers:

 - Firefox 36.0
 - Iceweasel 36.0
 - IceCat 31.4.0

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Changed in firefox (Ubuntu):
importance: Undecided → Medium
Changed in hundredpapercuts:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Jeffrey DeLeo (jeffreydeleo) wrote :

I am seeing the same problem clicking on a link from emacs - where it used to go to the link, now I just get a new window.
Can get some links to work - clicking a link in terminal, and selecting "open link", works OK.
Notice that "/usr/share/applications/firefox.desktop" was just changed, is there a change in option syntax?

Revision history for this message
In , Hjudt-l (hjudt-l) wrote :
Revision history for this message
Marcin Sochacki (wanted) wrote :

The root cause is removing the "-remote" option in Firefox 36:
https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#Remote_Control
https://bugzilla.mozilla.org/show_bug.cgi?id=1080319

I'm running XFCE and the option is used in /usr/share/xfce4/helpers/firefox.desktop.

Workaround:
replace the last line in /usr/share/xfce4/helpers/firefox.desktop with:
X-XFCE-CommandsWithParameter=%B -new-tab "%s";%B "%s";

Revision history for this message
David Pottage (david-electric-spoon) wrote :

Thanks. @wanted

That workarround fixed the problem for me, and should be an easy fix for the Ubuntu package maintainers to put into the next release.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in exo (Ubuntu):
status: New → Confirmed
Revision history for this message
Ivan Frederiks (idfred) wrote :

@wanted

I think than one has to replace last two lines:

X-XFCE-Commands=%B -new-window "about:blank";%B;
X-XFCE-CommandsWithParameter=%B -new-tab "%s";%B %s;

Revision history for this message
Jeffrey DeLeo (jeffreydeleo) wrote :

Yes, the problem is the remote option going away. The emacs function "browse-url-firefox" uses the remote option on non-ms-dos systems. Changing that function to not use the remote option solves the problem.

Revision history for this message
Marcin Sochacki (wanted) wrote :

@idfred:
yes, of course that is the complete fix

affects: firefox → exo
Changed in firefox (Ubuntu):
status: Confirmed → Invalid
summary: - Links from thunderbird email do not work
+ Firefox no longer supports -remote parameter
Changed in exo:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :
affects: firefox (Ubuntu) → emacs-defaults (Ubuntu)
Changed in emacs-defaults (Ubuntu):
status: Invalid → Confirmed
affects: emacs-defaults (Ubuntu) → emacs24 (Ubuntu)
Revision history for this message
Marcin Sochacki (wanted) wrote :

Perhaps it would make sense to make a proactive search of other packages in Ubuntu (and Debian) which could be affected.

This tool can be of help:
https://codesearch.debian.net/results/remote.*openurl/page_0

Changed in exo (Ubuntu):
importance: Undecided → Medium
Revision history for this message
In , Evilpies (evilpies) wrote :

I opened bug 1138053 for this problem. I might be able to fix it.

Revision history for this message
In , Robert Krawitz (rlk-alum) wrote :

This is causing me a serious headache, in that I'm now no longer able to open links remotely.

Here's my use case. I'm logged in to my laptop, machineA (running linux with X11). However, I read email with emacs rmail on my server, machineB (the emacs is running on machineB, connecting to the display on machineA -- I ssh login to machineB).

The solutions proposed here would appear to create a new firefox running on machineB. That's not what I want. Aside from the performance penalty, it means that when I move machineA around (take it to work, or whatever), the firefox in question would go away.

I don't care about the -ping option. I start firefox on login, so it's always around; if for some reason it goes away, I just restart it.

The upshot is that there now appears to be no way to do this. I'm not willing to switch mailers or anything like that. I guess I'll have to back off to firefox 35 until this capability is restored.

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1425972

tags: added: iso-testing
Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Robert Krawitz from comment #34)
> This is causing me a serious headache, in that I'm now no longer able to
> open links remotely.
>
> Here's my use case. I'm logged in to my laptop, machineA (running linux
> with X11). However, I read email with emacs rmail on my server, machineB
> (the emacs is running on machineB, connecting to the display on machineA --
> I ssh login to machineB).
>
> The solutions proposed here would appear to create a new firefox running on
> machineB.

If I do:
  1. firefox
  2. ssh -X foo firefox -new-tab http://firefox.com

That opens a firefox.com tab in the firefox launched at step 1, which seems to be what you want to be happening. Note that there are a few things that can make this fail to work, but that should have always been the case: firefox on both ends much be running with the same username and same application name. For instance, if you run a firefox aurora on one end and plain firefox on the other, that won't work unless you pass -a firefox or firefox-dev depending on which end is which. Similarly, you need to pass -u username if the user names differ.

Revision history for this message
ajgreeny (ajg-charlbury) wrote :

This comment is copied from my entry in https://bugs.launchpad.net/ubuntu/+source/exo/+bug/1427144

I also had this problem, not only with links in Thunderbird but also in Libreoffice documents, which both opened Firefox at my chosen homepage, not the link URL.
I have always changed my Preferred Application setting in XFCE Settings-manager to firefox rather than Debian Sensible Browser which is the default, and this never before caused any problem. With the upgrade to FF36 this seems to have broken.
Changing the Preferred Application back to Debian Sensible Browser seems to have fixed this and links are again opening in Firefox to the URL of the clicked link.

I have not tested George Shuklin's solution above yet, but will investigate later. (# NB This comment relates to the bug I mention above, not this one so the solution from George is there, not here.)

I have responded to a Ubuntuforum post with this and previous workarounds for this problem
See http://ubuntuforums.org/showthread.php?t=2267439

I am using Xubuntu 14.04.2 64bit.
uname -a output:-
Linux XubuntuTrusty 3.13.0-46-generic #76-Ubuntu SMP Thu Feb 26 18:52:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Revision history for this message
In , Korobkin+mozilla (korobkin+mozilla) wrote :

This broke a demo kiosk application that I have, and solutions proposed don't seem to work because firefox -url always opens a new window or tab. My config is simple:
a script is cycling through a list of URLs and opens them one after another, reusing the same tab.

Now if I replace it with firefox -url 'url' or firefox 'url', it open a new tab every time a new URL is passed, so Firefox has a ton of tabs in a couple of hours.

Is there a way to open every URL in the same tab from the command line?

Revision history for this message
In , Neil-httl (neil-httl) wrote :

(In reply to Alex K from comment #36)
> Is there a way to open every URL in the same tab from the command line?

Try setting browser.link.open_newwindow.override.external to 1. (It used to be called browser.link.open_external before bug 324164 and bug 509664.)

Revision history for this message
Unit 193 (unit193) wrote :

Attached is a debdiff for trusty.

Revision history for this message
Unit 193 (unit193) wrote :
Revision history for this message
Unit 193 (unit193) wrote :
Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

See comment 0, use -new-tab.

Revision history for this message
In , Carlo de Wolf (wolfc) wrote :

Regression in xfce4 (on Fedora 20).

As a work-around:
$ mkdir -p .local/share/xfce4/helpers
$ cp /usr/share/xfce4/helpers/firefox.desktop ~/.local/share/xfce4/helpers/firefox.desktop
$ patch -p0 <<EOF
--- ./.local/share/xfce4/helpers/firefox.desktop 2013-08-03 13:48:31.000000000 +0200
+++ ./.local/share/xfce4/helpers/firefox.desktop 2015-03-03 12:41:52.370528712 +0100
@@ -53,5 +53,5 @@
 StartupNotify=false
 X-XFCE-Binaries=firefox;firefox-gtk2;firefox-gtk;mozilla-firefox;
 X-XFCE-Category=WebBrowser
-X-XFCE-Commands=%B -remote "openURL(about:blank,new-window)";%B;
-X-XFCE-CommandsWithParameter=%B -remote "openURL(%s)";%B %s;
+X-XFCE-Commands=%B;%B;
+X-XFCE-CommandsWithParameter=%B "%s";%B %s;
EOF

Revision history for this message
In , Don Barry (don-4) wrote :

I'd really like to urge consideration of reversion of this removal.

The command line is in some ways the equivalent of the system call interface of the kernel: it's the way that other programs can instantiate a browser. As is becoming clear as people upgrade -- there are quite a few of these! I use, among other things, a very rusty environment which has Eclipse's odd help system: it fires up a browser via the -remote call -- and has worked for a decade. And now it's broken.

The command line should really be considered to be quite stable. Keep compatibility with old forms like -remote, even if if it is only to make them "mostly" compatible by filtering them into new and preferred forms. Preserve past functionality, while you build new: isn't that why content still renders from HTML 1.0?

Revision history for this message
In , Noitidart (noitidart) wrote :

My addon profilist is based on -P and -profile launching single instance. unless -no-remote is attached with it.

however it would be extremely useful to remote to the other profiles. i saw mention of a "new way of remoting"? can we please get info on that. ideally the old command lines should have just hooked into the new ones, updating the backend, if a change was really needed. but we can cope just show us how to remote the new pretty please.

Revision history for this message
In , Noitidart (noitidart) wrote :

Multi profile heavily relies on this. When users click a link and they have multiple profiles open i like to give them an option into which browser to open. It's a big deal if it opens in the wrong one, because say they didn't want to mix cookies because websites track them etc.

Here's the multi profile work i'm working on right now: https://github.com/Noitidart/Profilist/issues/18#issuecomment-46795390

Revision history for this message
cousteau (cousteaulecommandant) wrote :

When is a patch coming to precise?

Revision history for this message
In , john pleasa (jzigpublic) wrote :

*** Bug 11631 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Robert Krawitz (rlk-alum) wrote :

What Don Barry said. There's some amount of software out there that has to be rewritten because of this, and it appears to have been done without notice.

Emacs, for example, needs browse-url-firefox to be rewritten. It's not complicated to do, but it does mean that browsing URL's from emacs is broken for me until I get around to spending a few minutes on it, and for everyone else until the emacs maintainers code this up and do a release, and the various Linux distributions push the release.

Revision history for this message
In , lilydjwg (lilydjwg) wrote :

Python has an issue with this too. So I can't view HTML messages from mutt as the helper script is written in Python, my script opens wrong places, etc.

Link: http://bugs.python.org/issue23262

Revision history for this message
In , Evilpies (evilpies) wrote :

I asked about this on IRC and in general there seems to be support for reverting this change.

Revision history for this message
In , Jmizell (jmizell) wrote :

(In reply to Tom Schuster [:evilpie] from comment #45)
> I asked about this on IRC and in general there seems to be support for
> reverting this change.

This is a significant enough issue for my company, that we're planning on patching and compiling Firefox to get this back.

Revision history for this message
In , Evilpies (evilpies) wrote :

Backing out this change seems trivial, in which branches should/could we land this?

Revision history for this message
In , Sledru (sledru) wrote :

It seems that the impact of this change is quite high for a low gain.

Benjamin, Mike, do you agree? Thanks

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Sylvestre Ledru [:sylvestre] from comment #48)
> It seems that the impact of this change is quite high for a low gain.
>
> Benjamin, Mike, do you agree? Thanks

Thanks all for this. If they do agree, we're hoping for a 36.0.1 release so we don't have to make exceptions in all our other softwares etc to handle FF 36 in a special way. What is the "new way of remoting" btw? I saw these words in this topic but did not see the method outlined.

Revision history for this message
In , Rjesup (rjesup) wrote :

FYI, some testing (on a local m-c build), Fedora 21 x64:

Given: running one browser with just -P profile

From a shell:

running /usr/bin/firefox -new-tab http://mozilla.org/ -- new instance (asks for profile)
running ~/src/mozilla/m-c/obj*/dist/bin/firefox -new-tab http://mozilla.org/ -- new instance (asks for profile)
Checking "Start this profile automatically", retry - same result, doesn't ask first

From emacs, it used to invoke /usr/lib64/xulrunner/mozilla-xremote-client -remote -new-tab url -- this just worked. Not anymore (with or without -remote). Also, with the xremote, it sits for a long time trying to ping().

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

This probably can't be fixed by a backout by now. However, as mentioned in comment 7, it can be restore with an addon, modulo bug 1138053 and maybe a glitch with the profile manager. Or in browser code only. But that should be a separate bug imho.

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Mike Hommey [:glandium] from comment #51)
> This probably can't be fixed by a backout by now. However, as mentioned in
> comment 7, it can be restore with an addon, modulo bug 1138053 and maybe a
> glitch with the profile manager. Or in browser code only. But that should be
> a separate bug imho.

Can you please elaborate on how to implement it back with an addon. You guys are probably busy, but if you have the research/know how already, if you guys could write us a script that we can drop in our addons that would be awesome. I'm busy working on other aspects of multi profile addon to step back immediately to start working on this. :(

Revision history for this message
Brian Murray (brian-murray) wrote : Missing SRU information

Thanks for uploading the fix for this bug report to -proposed. However, when reviewing the package in -proposed and the details of this bug report I noticed that the bug description is missing information required for the SRU process. You can find full details at http://wiki.ubuntu.com/StableReleaseUpdates#Procedure but essentially this bug is missing some of the following: a statement of impact, a test case and details regarding the regression potential. Thanks in advance!

Revision history for this message
Brian Murray (brian-murray) wrote :

The convention for package version is to use the release so instead of 0.10.2-4ubuntu0.2 use 0.10.2-4ubuntu0.14.10.1. With the version numbers that you've used if the Trusty version of the package needs an update that the Utopic version doesn't we'll need to become creative with the version numbers. See the following link for the convention:

https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging

Revision history for this message
Brian Murray (brian-murray) wrote :

Actually 0.10.2-4, isn't even in trusty so the version number for the trusty upload makes even less sense.

Revision history for this message
In , Kbrosnan-mozilla (kbrosnan-mozilla) wrote :

The code landed. This bug should stay fixed unless the change gets backed out.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in emacs24 (Ubuntu Trusty):
status: New → Confirmed
Changed in emacs24 (Ubuntu Utopic):
status: New → Confirmed
Changed in exo (Ubuntu Trusty):
status: New → Confirmed
Changed in exo (Ubuntu Utopic):
status: New → Confirmed
Revision history for this message
Damian Yerrick (tepples) wrote :

Just in case others are searching for the symptoms I'm seeing in Xubuntu 14.04:

* Following links in XChat opens a new empty Firefox window
* ubuntu-bug opens a new empty Firefox window

Sean Davis (bluesabre)
description: updated
Sean Davis (bluesabre)
Changed in exo (Ubuntu Utopic):
status: Confirmed → In Progress
Revision history for this message
Sean Davis (bluesabre) wrote :

Attaching debdiff for trusty.

Changed in exo (Ubuntu Trusty):
status: Confirmed → In Progress
Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :
Revision history for this message
In , Robert Krawitz (rlk-alum) wrote :

What does "albeit working slightly differently" mean? Will scripts using the old CLI work unmodified?

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Robert Krawitz from comment #55)
> What does "albeit working slightly differently" mean? Will scripts using
> the old CLI work unmodified?

Depends what the scripts do. Version 0.0.2 should work with the vast majority.

Revision history for this message
In , Robert Krawitz (rlk-alum) wrote :

That's not very useful; what are the "slight differences"?

Revision history for this message
In , Don Barry (don-4) wrote :

While appreciative of the offer for an addon, I really urge consideration that this is a historic API, widely used -- and thus should be preserved, awkward or not. I understand the desire for cleanup, but this is how a significant body of code interfaces with the browser. There will be nothing to indicate to users of that code, when things now break, that they need to suddenly install an addon to activate an interface which has been there for years. For something like a browser, the command line *is* an API to external programs. Stability of APIs, even bad ones, is a good thing. In this case, it doesn't seem that it's consuming an inordinate amount of code, thus arguing for stability over cleanup.

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Don Barry from comment #58)
> While appreciative of the offer for an addon, I really urge consideration
> that this is a historic API, widely used -- and thus should be preserved,
> awkward or not. I understand the desire for cleanup, but this is how a
> significant body of code interfaces with the browser. There will be nothing
> to indicate to users of that code, when things now break, that they need to
> suddenly install an addon to activate an interface which has been there for
> years. For something like a browser, the command line *is* an API to
> external programs. Stability of APIs, even bad ones, is a good thing. In
> this case, it doesn't seem that it's consuming an inordinate amount of code,
> thus arguing for stability over cleanup.

Thanks Don. Your explanation makes a ton of sense, and points to implementing fix in like 36.0.1 do you think that would be possible? Lots broke :(

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Kevin Brosnan [:kbrosnan] from comment #53)
> The code landed. This bug should stay fixed unless the change gets backed
> out.

(In reply to Mike Hommey [:glandium] from comment #54)
> This should do the work:
> https://addons.mozilla.org/en-US/firefox/addon/restore-remote/

Thanks for this addon i didnt realize how inconvenient providing this via addon would be. I use profiles on the fly i have to install this to every profile. If we can get this fixed in 36.0.1 this would save the day.

It would also be nice if we can make sure its working on Windows Mac and Unix's. I started testing it just a few weeks ago and it wasnt working, on win8.1 but i was on beta channel so that may explain why it wasnt working for me on windows: https://bugzilla.mozilla.org/show_bug.cgi?id=1133731

Revision history for this message
In , Robert Krawitz (rlk-alum) wrote :

The real point here is that changing, or removing, an API without a very good reason just makes life difficult for users. In this case it's not at all apparent what the rationale is other than "cleanup", which doesn't seem like a very strong reason, especially since the functionality isn't being removed -- it's being provided, but with a different API. The effect on the end user is that common operations break for no apparent reason.

Saying that an extension will work "with slight differences" isn't really any better; it's not obvious to look for this extension, and it's certainly not obvious what "slight differences" means.

This kind of thing contributes to a perception (reality, really) of instability. That's not a good thing for end users.

Revision history for this message
In , Yisheng-dev (yisheng-dev) wrote :

I wish I had found this earlier, but my code breaking with the last update seems to have 'informed' me... :( I too have a big problem with removing this.

Any suggestions in this new world on how the following might be implemented? Essentially part of a bigger program that gives a menu of profiles to invoke, creates a new window if it's the first instance of that profile, or adds on if not (to get around 'firefox is already running' error). Using -no-remote doesn't work and all new instances now either fail or open in the first profile called with other variations tried.

1) firefox -P generic1 -remote "ping()"
   if [ ! $? == 0 ]; then
 nohup firefox -P generic1 -new-instance $URL 2>&1 >/dev/null &
   else
 nohup firefox -P generic1 -remote "openurl($URL,new-window)" 2>&1>/dev/null &
   fi
 ;;

Revision history for this message
In , Yisheng-dev (yisheng-dev) wrote :

To update after installing the restore-remote add-in, assume cases 1,2,3... from above. I start 1. I then start 2. It doesn't complain, but the new window is in profile 1, not 2!

Also tested with instances of 1 and 2 running, then opening another telling it profile 2. It came up in profile 1, which was the first one started of the 3 windows...

Still need a working method.

Revision history for this message
Yetisaurus Akjas (eduard-budai) wrote :

In Xubuntu 12.04.5 with xfdesktop 4.8.3-2ubuntu7 clicking links in pidgin 1:2.10.3-0ubuntu1.6 opens a Firefox new window with the homepage set in Firefox, although clicking links in e-mails in thunderbird 1:31.5.0+build1-0ubuntu0.12.04.1 opens the link in a new Firefox tab (normal/expected bahviour).

My last lines in /usr/share/xfce4/helpers/firefox.desktop are:

X-XFCE-Binaries=firefox;firefox-gtk2;firefox-gtk;mozilla-firefox;
X-XFCE-Category=WebBrowser
X-XFCE-CommandsWithParameter=%B -new-tab "%s)";%B %s;

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Created attachment 8573128
Backout the part that removed -remote

Approval Request Comment
[Feature/regressing bug #]: this bug
[User impact if declined]: Among many things, python's webbrowser module doesn't work properly.
[Describe test coverage new/current, TreeHerder]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8d349c9a6d0 (this is orange because I changed the mozconfigs to match those of release)
[Risks and why]: This is the opposite of the patch that landed, except for the removal of the mozilla-xremote-client executable, which stays removed. Call that a partial backout. This is the low-risk option. Other branches will be dealt with differently. -release needs something simple.
[String/UUID change made/needed]: None

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :
Revision history for this message
In , Catalin-varga (catalin-varga) wrote :

I verified if disabled on:

FF 36.0.1
Build Id:20150305021524
OS: Ubuntu 14.04 x64

The following commands:

-remote 'openURL(url)'
-remote 'openURL(url,new-tab)'
-remote 'openURL(url,new-window)'
-remote 'openfile(file)'

were verified and are working properly.

Revision history for this message
In , Greg Klanderman (gak-k) wrote :

It would be really nice if -new-window and -new-tab had the same behavior whether or not a browser is already running. Currently if no browser is running, 'firefox -new-window <url>' does not exit with a status code after the URL is opened (i.e. it waits for all windows to be closed before exiting), however if a browser is already running, this command does exit immediately, presumably with a status code indicating success.

Revision history for this message
In , Jmizell (jmizell) wrote :

(In reply to Catalin Varga [QA][:VarCat] from comment #66)
> I verified if disabled on:
>
> FF 36.0.1
> Build Id:20150305021524
> OS: Ubuntu 14.04 x64
>
> The following commands:
>
> -remote 'openURL(url)'
> -remote 'openURL(url,new-tab)'
> -remote 'openURL(url,new-window)'
> -remote 'openfile(file)'
>
> were verified and are working properly.

How about -remote 'ping()', or is that not supported with this reversion?

The way the old code worked, I needed to first detect if a firefox profile was running before I could do a -remote 'openURL(url,new-window)', otherwise I needed to do -new-instance url.

Here's an example of what I'm doing to launch windows into two different simultanously running firefox profiles.

if $firefoxpath -P $profile -remote 'ping()' > /dev/null 2>&1; then
  $firefoxpath -P $profile -remote "openurl($url,new-window)"
else
  $firefoxpath -P $profile -new-instance $url
fi

Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello David, or anyone else affected,

Accepted exo into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/exo/0.10.2-3ubuntu1.14.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in exo (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Ang Bongsong (notinsideofhereiamnotinside) wrote :

I can confirm this bug, and that the fix mentioned in comment #7 (https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/7) resolves it.

Revision history for this message
In , Evangelos Foutras (foutrelis) wrote :

FTR, Firefox 36.0.1 has restored the -remote option as it broke many use cases without any real benefit. We could possibly revert commit 8022a52 in exo, though I can't think of an upside to using -remote in this context.

Revision history for this message
Greg (thorn-m) wrote :

# 7 fixed it for me too. Clicking on links in Thunderbird that went to a new blank Firefox window was driving me crazy after the recent update.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu Trusty):
status: New → Confirmed
Changed in firefox (Ubuntu Utopic):
status: New → Confirmed
Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
Jochen Seidel (x+launchpad) wrote :

The proposed package fixed the bug for me.

tags: added: verification-done-trusty
removed: verification-needed
Revision history for this message
Ivan Frederiks (idfred) wrote :

LOL, Firefox developers returned -remote option in 36.0.1

Revision history for this message
Mathew Hodson (mhodson) wrote :
Revision history for this message
In , Main-haarp (main-haarp) wrote :

(In reply to Evangelos Foutras from comment #6)
> FTR, Firefox 36.0.1 has restored the -remote option as it broke many use
> cases without any real benefit. We could possibly revert commit 8022a52 in
> exo, though I can't think of an upside to using -remote in this context.

Seeing as -remote seems to enjoy a semi-deprecated status now, it's probably best to avoid it if possible for the time being.

Changed in exo (Debian):
status: Unknown → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 36.0.1+build2-0ubuntu1

---------------
firefox (36.0.1+build2-0ubuntu1) vivid; urgency=medium

  * New upstream stable release (FIREFOX_36_0_1_BUILD2)
    - see LP: #1429115
    - revert removal of the deprecated -remote command line option, as some
      older software (eg, Python 2.7's webbrowser module) still depends on it
      (LP: #1425972)
 -- Chris Coulson <email address hidden> Fri, 06 Mar 2015 12:42:38 +0000

Changed in firefox (Ubuntu):
status: Confirmed → Fix Released
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
In , Noitidart (noitidart) wrote :

Quick update, another thing this broke is the Windows 7 + jump menu:
http://i.imgur.com/OiyEzUI.png

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to noitidart from comment #69)
> Quick update, another thing this broke is the Windows 7 + jump menu:
> http://i.imgur.com/OiyEzUI.png

This makes no sense, those are not using -remote: https://dxr.mozilla.org/mozilla-central/source/browser/modules/WindowsJumpLists.jsm#91

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Mike Hommey [:glandium] from comment #70)
> (In reply to noitidart from comment #69)
> > Quick update, another thing this broke is the Windows 7 + jump menu:
> > http://i.imgur.com/OiyEzUI.png
>
> This makes no sense, those are not using -remote:
> https://dxr.mozilla.org/mozilla-central/source/browser/modules/
> WindowsJumpLists.jsm#91

Ah you're right excuse that then. I don't know why it keeps telling me "Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window".

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 36.0.1+build2-0ubuntu0.14.10.1

---------------
firefox (36.0.1+build2-0ubuntu0.14.10.1) utopic-security; urgency=medium

  * New upstream stable release (FIREFOX_36_0_1_BUILD2)
    - see LP: #1429115
    - revert removal of the deprecated -remote command line option, as some
      older software (eg, Python 2.7's webbrowser module) still depends on it
      (LP: #1425972)
 -- Chris Coulson <email address hidden> Fri, 06 Mar 2015 12:43:36 +0000

Changed in firefox (Ubuntu Utopic):
status: Confirmed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 36.0.1+build2-0ubuntu0.14.04.1

---------------
firefox (36.0.1+build2-0ubuntu0.14.04.1) trusty-security; urgency=medium

  * New upstream stable release (FIREFOX_36_0_1_BUILD2)
    - see LP: #1429115
    - revert removal of the deprecated -remote command line option, as some
      older software (eg, Python 2.7's webbrowser module) still depends on it
      (LP: #1425972)
 -- Chris Coulson <email address hidden> Fri, 06 Mar 2015 12:44:25 +0000

Changed in firefox (Ubuntu Trusty):
status: Confirmed → Fix Released
Revision history for this message
In , Liquitsnake (liquitsnake) wrote :

Just a note, the documentation should be updated that the feature has been re-included.

https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-remote_remote_command

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to haarp from comment #72)
> Just a note, the documentation should be updated that the feature has been
> re-included.
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-
> remote_remote_command

Ok i can do that. Should i update it to say:
"Not availabile in Gecko 36.0, but available again since Gecko ?.?"

What should i put for "?.?"?

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

It's in 36.0.1, but it's guaranteed to still be there in 37.

Revision history for this message
In , Jypenator (jypenator) wrote :

So, if I'm following correctly: -remote was removed in Fx 36, readded in the chemspill 36.0.1 and won't be removed in 37 at least?

Is this correct (We also need to update Fx 36 for devs).

A tip that we'll help us: if you back-out a bug that has "dev-doc-complete", please turn it back to "dev-doc-needed", so the doc team is aware of the change.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to Jean-Yves Perrier [:teoli] from comment #75)
> So, if I'm following correctly: -remote was removed in Fx 36, readded in the
> chemspill 36.0.1 and won't be removed in 37 at least?
>
> Is this correct (We also need to update Fx 36 for devs).

Err, I missed a not in my sentence. It is *not* guaranteed to still be there in 37.

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Mike Hommey [:glandium] from comment #74)
> It's in 36.0.1, but it's guaranteed to still be there in 37.

Awesome thanks ill check docs and update if its not updated yet!

Revision history for this message
In , Noitidart (noitidart) wrote :

I don't think this works on windows.

I opened my 2nd profile with this:
firefox.exe -P Dev -no-remote

Then tried to open a new tab in that profile with this:
firefox.exe -P Dev -remote "openURL(http://www.bing.com,new-tab)"

it didnt work :(

Revision history for this message
In , pav (pav-7) wrote :

(In reply to noitidart from comment #78)
> I opened my 2nd profile with this:
> firefox.exe -P Dev -no-remote

Try "firefox.exe -P Dev -new-instance"

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Pavlos Touboulidis from comment #79)
> (In reply to noitidart from comment #78)
> > I opened my 2nd profile with this:
> > firefox.exe -P Dev -no-remote
>
> Try "firefox.exe -P Dev -new-instance"

Thanks Pavlos I tried that.

1) firefox.exe -P Dev -new-instance
2) it opened new window of the current profile already open, it did not open my proflie named Dev

So i tried this:
1) firefox.exe -P Dev -new-instance -no-remote

this opened my profiled named Dev in parallel/concurrent to my other running profile
I then tried to remote it:
2) firefox.exe -P Dev -remote "openURL(http://www.bing.com,new-tab)"

but it just opens a new window in my first running profile, and it doesnt even point to bing.com just the homepage of that first running profile :(

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to noitidart from comment #80)
> (In reply to Pavlos Touboulidis from comment #79)
> > (In reply to noitidart from comment #78)
> > > I opened my 2nd profile with this:
> > > firefox.exe -P Dev -no-remote
> >
> > Try "firefox.exe -P Dev -new-instance"
>
> Thanks Pavlos I tried that.
>
> 1) firefox.exe -P Dev -new-instance
> 2) it opened new window of the current profile already open, it did not open
> my proflie named Dev
>
> So i tried this:
> 1) firefox.exe -P Dev -new-instance -no-remote
>
> this opened my profiled named Dev in parallel/concurrent to my other running
> profile
> I then tried to remote it:
> 2) firefox.exe -P Dev -remote "openURL(http://www.bing.com,new-tab)"
>
> but it just opens a new window in my first running profile, and it doesnt
> even point to bing.com just the homepage of that first running profile :(

That's bug 1138053 and it's fixed in nightly. Use -new-tab instead of -remote, though.

Mathew Hodson (mhodson)
Changed in emacs:
status: New → Fix Released
Mathew Hodson (mhodson)
affects: hundredpapercuts → python
Changed in python:
importance: Medium → Unknown
status: Confirmed → Unknown
Mathew Hodson (mhodson)
Changed in emacs:
importance: Undecided → Unknown
status: Fix Released → Unknown
Changed in python:
status: Unknown → New
Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Comment on attachment 8573128
Backout the part that removed -remote

Approval Request Comment: See comment 64

Considering how late we are in the beta cycle, it's more reasonable to get this on 37. 38 will get the alternative approach.

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Mike Hommey [:glandium] from comment #82)
> Comment on attachment 8573128
> Backout the part that removed -remote
>
> Approval Request Comment: See comment 64
>
> Considering how late we are in the beta cycle, it's more reasonable to get
> this on 37. 38 will get the alternative approach.

Aw darn are you sure we can't land it in 36? Then for backwards compatability addons have to work in an exception for just FF36. :( And I know software like Notepad++ and other softwares won't add in an exception for FF36. It will impact ESR when it gets to FF36 for the longest amount of time.

Just sharing my thoughts on some ways it hurts if we cant get it into FF36 but I appreciate you guys bringing it back, even if it doesnt get to FF36.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to noitidart from comment #83)
> (In reply to Mike Hommey [:glandium] from comment #82)
> > Comment on attachment 8573128
> > Backout the part that removed -remote
> >
> > Approval Request Comment: See comment 64
> >
> > Considering how late we are in the beta cycle, it's more reasonable to get
> > this on 37. 38 will get the alternative approach.
>
> Aw darn are you sure we can't land it in 36? Then for backwards
> compatability addons have to work in an exception for just FF36. :( And I
> know software like Notepad++ and other softwares won't add in an exception
> for FF36. It will impact ESR when it gets to FF36 for the longest amount of
> time.
>
> Just sharing my thoughts on some ways it hurts if we cant get it into FF36
> but I appreciate you guys bringing it back, even if it doesnt get to FF36.

Do you mean 38 everywhere you wrote 36? Do you also mean that notepad++ on windows is actually using the -remote option? And what addons are you talking about? Addons should not care about Firefox command line.

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Mike Hommey [:glandium] from comment #84)
> (In reply to noitidart from comment #83)
> > (In reply to Mike Hommey [:glandium] from comment #82)
> > > Comment on attachment 8573128
> > > Backout the part that removed -remote
> > >
> > > Approval Request Comment: See comment 64
> > >
> > > Considering how late we are in the beta cycle, it's more reasonable to get
> > > this on 37. 38 will get the alternative approach.
> >
> > Aw darn are you sure we can't land it in 36? Then for backwards
> > compatability addons have to work in an exception for just FF36. :( And I
> > know software like Notepad++ and other softwares won't add in an exception
> > for FF36. It will impact ESR when it gets to FF36 for the longest amount of
> > time.
> >
> > Just sharing my thoughts on some ways it hurts if we cant get it into FF36
> > but I appreciate you guys bringing it back, even if it doesnt get to FF36.
>
> Do you mean 38 everywhere you wrote 36? Do you also mean that notepad++ on
> windows is actually using the -remote option? And what addons are you
> talking about? Addons should not care about Firefox command line.

No man I was hoping for FF36 :( I'm addon dev and I use this command line.

Also this very popular addon uses the remote feature: https://addons.mozilla.org/en-US/firefox/addon/profileswitcher/

Yep Notepad++ when you do preview in webbrowser it wont open.
Also Camtasia screen recording software it wont open the generated video in firefox for preview/youtube.

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

(In reply to noitidart from comment #85)
> (In reply to Mike Hommey [:glandium] from comment #84)
> > (In reply to noitidart from comment #83)
> > > (In reply to Mike Hommey [:glandium] from comment #82)
> > > > Comment on attachment 8573128
> > > > Backout the part that removed -remote
> > > >
> > > > Approval Request Comment: See comment 64
> > > >
> > > > Considering how late we are in the beta cycle, it's more reasonable to get
> > > > this on 37. 38 will get the alternative approach.
> > >
> > > Aw darn are you sure we can't land it in 36? Then for backwards
> > > compatability addons have to work in an exception for just FF36. :( And I
> > > know software like Notepad++ and other softwares won't add in an exception
> > > for FF36. It will impact ESR when it gets to FF36 for the longest amount of
> > > time.
> > >
> > > Just sharing my thoughts on some ways it hurts if we cant get it into FF36
> > > but I appreciate you guys bringing it back, even if it doesnt get to FF36.
> >
> > Do you mean 38 everywhere you wrote 36? Do you also mean that notepad++ on
> > windows is actually using the -remote option? And what addons are you
> > talking about? Addons should not care about Firefox command line.
>
> No man I was hoping for FF36 :( I'm addon dev and I use this command line.

-remote was restored in 36.0.1 already. But maybe you're still talking about comment 80? In which case, it is not related to this bug.

> Yep Notepad++ when you do preview in webbrowser it wont open.

I just tested, and it works. Also, Notepad++ doesn't use -remote, it just invokes "firefox.exe edited-file-name".

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Mike Hommey [:glandium] from comment #86)
> (In reply to noitidart from comment #85)
> > (In reply to Mike Hommey [:glandium] from comment #84)
> > > (In reply to noitidart from comment #83)
> > > > (In reply to Mike Hommey [:glandium] from comment #82)
> > > > > Comment on attachment 8573128
> > > > > Backout the part that removed -remote
> > > > >
> > > > > Approval Request Comment: See comment 64
> > > > >
> > > > > Considering how late we are in the beta cycle, it's more reasonable to get
> > > > > this on 37. 38 will get the alternative approach.
> > > >
> > > > Aw darn are you sure we can't land it in 36? Then for backwards
> > > > compatability addons have to work in an exception for just FF36. :( And I
> > > > know software like Notepad++ and other softwares won't add in an exception
> > > > for FF36. It will impact ESR when it gets to FF36 for the longest amount of
> > > > time.
> > > >
> > > > Just sharing my thoughts on some ways it hurts if we cant get it into FF36
> > > > but I appreciate you guys bringing it back, even if it doesnt get to FF36.
> > >
> > > Do you mean 38 everywhere you wrote 36? Do you also mean that notepad++ on
> > > windows is actually using the -remote option? And what addons are you
> > > talking about? Addons should not care about Firefox command line.
> >
> > No man I was hoping for FF36 :( I'm addon dev and I use this command line.
>
> -remote was restored in 36.0.1 already. But maybe you're still talking about
> comment 80? In which case, it is not related to this bug.
>
> > Yep Notepad++ when you do preview in webbrowser it wont open.
>
> I just tested, and it works. Also, Notepad++ doesn't use -remote, it just
> invokes "firefox.exe edited-file-name".

Ohh! Thanks for the clarificaiton! Excuse that mixup im going to go to sleep late here :P

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :

Comment on attachment 8573128
Backout the part that removed -remote

That being said, I can see a point in being more conservative for the upcoming ESR.

Revision history for this message
In , Noitidart (noitidart) wrote :

(In reply to Mike Hommey [:glandium] from comment #88)
> Comment on attachment 8573128
> Backout the part that removed -remote
>
> That being said, I can see a point in being more conservative for the
> upcoming ESR.

thanks :)

Revision history for this message
In , Ryanvm (ryanvm) wrote :
Revision history for this message
In , Robert Krawitz (rlk-alum) wrote :

It isn't clear to me what the final resolution is. Is -remote going to stay, or will it be removed?

-remote has been part of the API for quite a long time. Pulling it without an _extended_ notification (on the order of a year, say) will inconvenience a lot of people. Firefox and Thunderbird are upgraded a lot more frequently than most packages, and you have no way of knowing what software out there relies on -remote. In particular, I know that GNU Emacs does, and it is not updated very often (the current release, 24.4, dates to 10/2014; the previous release, 24.3, dates to 03/2013).

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package exo - 0.10.2-3ubuntu1.14.04.2

---------------
exo (0.10.2-3ubuntu1.14.04.2) trusty-proposed; urgency=medium

  * Fix firefox helper being unable to open URLs (LP: #1425972)
 -- Sean Davis <email address hidden> Wed, 04 Mar 2015 19:02:35 -0500

Changed in exo (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Chris Halse Rogers (raof) wrote : Update Released

The verification of the Stable Release Update for exo has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
In , Moz-jeka (moz-jeka) wrote :

(In reply to Robert Krawitz from comment #91)
> It isn't clear to me what the final resolution is. Is -remote going to
> stay, or will it be removed?

See Tracking Flags in the header of this bug (where "fixed" means removed)

Revision history for this message
In , Ben-qolc (ben-qolc) wrote :

The release notes for 36.0.3 still claim that the -remote option has been removed, even though it now hasn't.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

ni Sylvestre for comment 93

Revision history for this message
In , Sledru (sledru) wrote :

Indeed. Removed. thanks

Changed in exo (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
In , Ancoron Luziferis (ancoron) wrote :

Hi, sorry to revive this old thread, but what is the actual replacement for "-remote" from a functional point of view? I am asking because "-new-tab" and "-new-window" just don't respect the "-P" profile switch.

Revision history for this message
In , Noitidart (noitidart) wrote :

Is it possible to `-remote restart -P "profile1"? I'm trying to restart profiles launched by `firefox -no-remote -P "profile_name_here"`?

Revision history for this message
In , U93378 (u93378) wrote :

Is this expected to work on Mac OS X? I try -remote, and things like:

/Applications/Firefox.app/Contents/MacOS/firefox -new-window "www.mozilla.org"

...and all I get is a modal dialog box saying that I have to close Firefox because only one instance can be running.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

No, Firefox for mac does not remote internally: that is all handled by the OS and apple events.

Revision history for this message
RichardNeill (ubuntu-richardneill) wrote :

This also breaks ubuntu-bug/apport-bug itself.
Report filed here: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1464053

Revision history for this message
In , U93378 (u93378) wrote :

(In reply to Benjamin Smedberg [:bsmedberg] from comment #99)
> No, Firefox for mac does not remote internally: that is all handled by the
> OS and apple events.

Would you please provide a pointer to some information about Apple Events and Firefox? Googling for mozilla and "apple event", firefox and "apple event", and thunderbird and "apple event" doesn't reveal anything.
Alas "Apple Event," just pollutes the search results with a lot of crap about Apple's product announcements :-(

Documentation for FF and TB doesn't clearly state that the command line arguments won't work on Mac OS X.

Indeed, this page https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#Mac_OS_X implies that command line arguments should work on Mac.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

There's the code at http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/MacApplicationDelegate.mm

I don't know who wrote or reviewed that MDN page, but it's clearly not precise: there are a fair number of flags that only apply on some platforms. It's still true that mac doesn't use any of the remoting flags: -remote, -no-remote, etc

Revision history for this message
In , Jypenator (jypenator) wrote :
Revision history for this message
In , Noitidart (noitidart) wrote :

For Windows I'm having a major issue. Clicking any of the items from multiple running profiles from the jump lists is either opening the window in default profile or saying "firefox is already running".

Is there any alternative to -remote? This is the relavent code thats bugging me out: https://dxr.mozilla.org/mozilla-central/source/browser/modules/WindowsJumpLists.jsm#107

You can see I tried to set -no-remote and -remote and -new-instance on these flags none of them work.

This is what I mean by multiple profiles in parallel: https://www.youtube.com/watch?v=fKw-BNWMyQM

Revision history for this message
In , U93378 (u93378) wrote :

(In reply to Jean-Yves Perrier [:teoli] from comment #102)
> I think
> https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-
> remote_remote_command is up-to-date.

If that command is not available on the Mac platform, and that fact is not noted, I don't see how we can regard it as up-to-date.

Also, for more detail, this documentation second points to a page (http://www-archive.mozilla.org/unix/remote.html) which is annotated as follows: "Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only." So that's another reason to regard this documentation as out-of-date.

That remote page describes the -remote command as being for "Unix" also, which is inaccurate, since Mac OS X is, at its core, a Unix platform. IIUC, what's actually going on is that the command is limited to X windows platforms, not Unix.

Revision history for this message
In , Eshepherd (eshepherd) wrote :

I've updated the article to note that this feature is x-Window only and done a bit of other cleanup. Let me know if it needs further changes.

Revision history for this message
In , Marsicanbear (marsicanbear) wrote :

I recently updated to Firefox-39 on Ubuntu 15.04 and this feature is broken again.

I use this script:

https://github.com/davidebasilio/firefox-kde

to bind Firefox profiles and kde sessions; it used to work fine, but now whenever I try to open a new page in an already open profile with:

/usr/bin/firefox -P $ACTIVITY -remote "openURL($url,new-tab)" &> /tmp/firefox-kde.log

I get the error dialog saying that Firefox is already running.

Revision history for this message
In , Tomiii-r (tomiii-r) wrote :

Like <email address hidden>, I also upgraded to FF39.0 in Fedora linux and discovered this feature broken again. The behavior seems nondeterministic now. I'm executing this command when no firefox instance with profile "myprofile" is currenty running:

firefox -P myprofile -remote 'ping()'

Sometimes I just get the prompt back with no visible side effect, sometimes I get a new instance of firefox that's already running using a different profile, and sometimes I get these error messages:

1437410472556 addons.xpi-utils ERROR Failed to load XPI JSON data from profile: TypeError: XPIProvider.installLocationsByName is null (resource://gre/modules/addons/XPIProvider.jsm -> resource://gre/modules/addons/XPIProviderUtils.js:312:4) JS Stack trace: <email address hidden>:312:5 < <email address hidden>:629:24 < XPIDB_asyncLoadDB/this._dbPromise<@XPIProviderUtils.js:732:9 < <email address hidden>:867:23 < <email address hidden>:746:7 < this.PromiseWalker.scheduleWalkerLoop/<@Promise-backend.js:688:37 < <email address hidden>:464:9
1437410472559 addons.xpi-utils WARN Rebuilding add-ons database from installed extensions.
1437410472561 addons.xpi-utils ERROR Failed to rebuild XPI database from installed extensions: TypeError: this.installLocations is null (resource://gre/modules/addons/XPIProvider.jsm:3365) JS Stack trace: <email address hidden>:3365:1 < <email address hidden>:779:9 < <email address hidden>:650:7 < XPIDB_asyncLoadDB/this._dbPromise<@XPIProviderUtils.js:732:9 < <email address hidden>:867:23 < <email address hidden>:746:7 < this.PromiseWalker.scheduleWalkerLoop/<@Promise-backend.js:688:37 < <email address hidden>:464:9
1437410472563 addons.manager ERROR Exception calling provider GMPProvider.getAddonByID: TypeError: this._plugins is null (resource://gre/modules/addons/GMPProvider.jsm:581:8) JS Stack trace: <email address hidden>:581:9 < <email address hidden>:235:12 < <email address hidden>:2109:1 < <email address hidden>:311:7 < <email address hidden>:2114:13 < <email address hidden>:423:7 < <email address hidden>:235:12 < <email address hidden>:2109:1 < <email address hidden>:311:7 < <email address hidden>:2114:13 < <email address hidden>:3824:7 < makeSafe/<@XPIProviderUtils.js:145:17 < <email address hidden>:126:5 < this.XPIDatabase.getAddon/<@XPIProviderUtils.js:1074:9 < <email address hidden>:867:23 < <email address hidden>:746:7 < this.PromiseWalker.scheduleWalkerLoop/<@Promise-backend.js:688:37 < <email address hidden>:464:9

Revision history for this message
In , Tomiii-r (tomiii-r) wrote :

Also, if an instance of firefox is already running with profile "myprofile" and I issue this command:

firefox -P myprofile -remote 'openurl(https://my.url.com/)'

Nothing happens. It just exits with no error message and $?==1.

Revision history for this message
In , Moz-jeka (moz-jeka) wrote :

(In reply to marsicanbear from comment #106)
> I recently updated to Firefox-39 on Ubuntu 15.04 and this feature is broken
> again.

see comment 92?

Revision history for this message
In , Marsicanbear (marsicanbear) wrote :

(In reply to j.j. from comment #109)
> (In reply to marsicanbear from comment #106)
> > I recently updated to Firefox-39 on Ubuntu 15.04 and this feature is broken
> > again.
>
> see comment 92?

The feature was removed in Firefox 36.0, but was restored in 36.0.1.

https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-remote_remote_command

And, afaik, it was supposed to stay there.

Revision history for this message
In , Moz-jeka (moz-jeka) wrote :

> > see comment 92?
>
> The feature was removed in Firefox 36.0, but was restored in 36.0.1.
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-
> remote_remote_command
>
> And, afaik, it was supposed to stay there.

No, comment 92 is right
> See Tracking Flags in the header of this bug (where "fixed" means removed)
"status-firefox39: fixed"

https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-remote_remote_command
Docs are wrong and need an update, thanks!
Setting keyword "dev-doc-needed" for that.

Revision history for this message
In , Marsicanbear (marsicanbear) wrote :

(In reply to j.j. from comment #111)
> No, comment 92 is right

OK, I see, so the -remote option was removed in 39.
I don't quite understand why it was reintroduced in 36.0.1, then.. But well, whatever. I guess that this time the decision is definitive.

Do you know if there is any other way to use different profiles at the same time to separate "activities"?

This feature was really cool for me to integrate my browsing with kde activities and it's the main reason I was using Firefox in the first place.

Mathew Hodson (mhodson)
Changed in exo (Ubuntu Utopic):
status: In Progress → Won't Fix
Changed in emacs24 (Ubuntu Utopic):
status: Confirmed → Won't Fix
Changed in emacs24 (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Mathew Hodson (mhodson) wrote :

According to the upstream bug this is fixed in emacs 24.5, which has been uploaded to Wily.

Changed in emacs24 (Ubuntu):
status: Triaged → Fix Released
Changed in emacs24 (Ubuntu Trusty):
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in exo (Ubuntu Trusty):
importance: Undecided → Medium
Mathew Hodson (mhodson)
Changed in emacs24 (Ubuntu Utopic):
importance: Undecided → Medium
Changed in exo (Ubuntu Utopic):
importance: Undecided → Medium
Mathew Hodson (mhodson)
Changed in firefox (Ubuntu):
importance: Undecided → High
Changed in firefox (Ubuntu Trusty):
importance: Undecided → High
Changed in firefox (Ubuntu Utopic):
importance: Undecided → High
Revision history for this message
In , Aurelien-pupier (aurelien-pupier) wrote :

Hi,

are you sure that this option was removed in version 39.0?
I just tried with version 40.0.3 and it seems to work.
The documentation is still mentioning it as existing https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-remote_remote_command even if marked as deprecated.
Can someone be clearer on the subject?

Regards,

Revision history for this message
In , Mh+mozilla (mh+mozilla) wrote :
Revision history for this message
In , Jypenator (jypenator) wrote :
Revision history for this message
In , Zaki210792 (zaki210792) wrote :

[Tracking Requested - why for this release]:

Changed in exo (Debian):
status: New → Fix Released
Mathew Hodson (mhodson)
Changed in emacs24 (Ubuntu Trusty):
status: Triaged → Won't Fix
Changed in python:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.