Firefox no longer supports -remote parameter

Bug #1425972 reported by David Pottage on 2015-02-26
214
This bug affects 42 people
Affects Status Importance Assigned to Milestone
GNU Emacs
Unknown
Unknown
Mozilla Firefox
Fix Released
Medium
Python
New
Unknown
exo
Fix Released
Medium
emacs24 (Ubuntu)
Medium
Unassigned
Trusty
Medium
Unassigned
Utopic
Medium
Unassigned
exo (Debian)
Fix Released
Unknown
exo (Ubuntu)
Medium
Unassigned
Trusty
Medium
Unassigned
Utopic
Medium
Unassigned
firefox (Ubuntu)
High
Unassigned
Trusty
High
Unassigned
Utopic
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.

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.

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

10 comments hidden view all 168 comments
11 comments hidden view all 168 comments

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

10 comments hidden view all 168 comments
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
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?

10 comments hidden view all 168 comments
9 comments hidden view all 168 comments
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";

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.

Launchpad Janitor (janitor) wrote :

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

Changed in exo (Ubuntu):
status: New → Confirmed
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;

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.

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
5 comments hidden view all 168 comments
affects: firefox (Ubuntu) → emacs-defaults (Ubuntu)
Changed in emacs-defaults (Ubuntu):
status: Invalid → Confirmed
affects: emacs-defaults (Ubuntu) → emacs24 (Ubuntu)
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
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
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

Unit 193 (unit193) wrote :

Attached is a debdiff for trusty.

Unit 193 (unit193) wrote :
Unit 193 (unit193) wrote :

When is a patch coming to precise?

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!

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

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.

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
3 comments hidden view all 168 comments
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) on 2015-03-04
description: updated
Sean Davis (bluesabre) on 2015-03-04
Changed in exo (Ubuntu Utopic):
status: Confirmed → In Progress
Sean Davis (bluesabre) wrote :

Attaching debdiff for trusty.

Changed in exo (Ubuntu Trusty):
status: Confirmed → In Progress

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;

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

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.

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.

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
2 comments hidden view all 168 comments
Jochen Seidel (x+launchpad) wrote :

The proposed package fixed the bug for me.

tags: added: verification-done-trusty
removed: verification-needed
Ivan Frederiks (idfred) wrote :

LOL, Firefox developers returned -remote option in 36.0.1

Changed in exo (Debian):
status: Unknown → New
Changed in firefox (Ubuntu):
status: Confirmed → Fix Released
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in firefox (Ubuntu Utopic):
status: Confirmed → Fix Released
Changed in firefox (Ubuntu Trusty):
status: Confirmed → Fix Released
88 comments hidden view all 168 comments

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

Changed in emacs:
status: New → Fix Released
affects: hundredpapercuts → python
Changed in python:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in emacs:
importance: Undecided → Unknown
status: Fix Released → Unknown
Changed in python:
status: Unknown → New

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.

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

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

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

(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".

(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

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.

(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 :)

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

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

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.

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

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

ni Sylvestre for comment 93

Indeed. Removed. thanks

Changed in exo (Ubuntu):
status: Confirmed → Fix Released
2 comments hidden view all 168 comments

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.

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

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.

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

4 comments hidden view all 168 comments

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

5 comments hidden view all 168 comments

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

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

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

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

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.

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.

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

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.

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

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

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

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

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
16 comments hidden view all 168 comments
Mathew Hodson (mathew-hodson) 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
Changed in emacs24 (Ubuntu Utopic):
importance: Undecided → Medium
Changed in exo (Ubuntu Utopic):
importance: Undecided → Medium
Changed in firefox (Ubuntu):
importance: Undecided → High
Changed in firefox (Ubuntu Trusty):
importance: Undecided → High
Changed in firefox (Ubuntu Utopic):
importance: Undecided → High
17 comments hidden view all 168 comments

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,

[Tracking Requested - why for this release]:

Changed in exo (Debian):
status: New → Fix Released
Displaying first 40 and last 40 comments. View all 168 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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