Firefox no longer supports -remote parameter
| 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://
Expected: Firefox opens at http://
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-
ProcVersionSign
Uname: Linux 3.16.0-31-generic x86_64
AddonCompatChec
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
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
IncompatibleExt
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-
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-
Plugins:
Shockwave Flash - /usr/lib/
LibreOffice Plug-in - /usr/lib/
Java(TM) Plug-in 11.25.2 - /usr/lib/
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=
RelatedPackageV
RfKill:
0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: no
RunningIncompat
SourcePackage: firefox
SubmittedCrashIDs: bp-86a16931-
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.
dmi.product.name: Vostro 270
dmi.sys.vendor: Dell Inc.
Related branches
|
|
#11 |
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.
|
|
#12 |
(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.
|
|
#13 |
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
| Launchpad Janitor (janitor) wrote : | #2 |
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 : | #3 |
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/
|
|
#14 |
| Marcin Sochacki (wanted) wrote : | #4 |
The root cause is removing the "-remote" option in Firefox 36:
https:/
https:/
I'm running XFCE and the option is used in /usr/share/
Workaround:
replace the last line in /usr/share/
X-XFCE-
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 : | #6 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in exo (Ubuntu): | |
| status: | New → Confirmed |
| Ivan Frederiks (idfred) wrote : | #7 |
@wanted
I think than one has to replace last two lines:
X-XFCE-Commands=%B -new-window "about:blank";%B;
X-XFCE-
| Jeffrey DeLeo (jeffreydeleo) wrote : | #8 |
Yes, the problem is the remote option going away. The emacs function "browse-
| Marcin Sochacki (wanted) wrote : | #9 |
@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 |
Fixed upstream (emacs-24):
| affects: | firefox (Ubuntu) → emacs-defaults (Ubuntu) |
| Changed in emacs-defaults (Ubuntu): | |
| status: | Invalid → Confirmed |
| affects: | emacs-defaults (Ubuntu) → emacs24 (Ubuntu) |
| Marcin Sochacki (wanted) wrote : | #16 |
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:/
| Changed in exo (Ubuntu): | |
| importance: | Undecided → Medium |
| Ubuntu QA Website (ubuntuqa) wrote : | #17 |
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://
| tags: | added: iso-testing |
| ajgreeny (ajg-charlbury) wrote : | #18 |
This comment is copied from my entry in https:/
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://
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 : | #19 |
Attached is a debdiff for trusty.
| Unit 193 (unit193) wrote : | #20 |
| Unit 193 (unit193) wrote : | #21 |
| cousteau (cousteaulecommandant) wrote : | #22 |
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://
| Brian Murray (brian-murray) wrote : | #24 |
The convention for package version is to use the release so instead of 0.10.2-4ubuntu0.2 use 0.10.2-
https:/
| Brian Murray (brian-murray) wrote : | #25 |
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 : | #26 |
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 |
| Damian Yerrick (tepples) wrote : | #30 |
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
| description: | updated |
| Changed in exo (Ubuntu Utopic): | |
| status: | Confirmed → In Progress |
| Sean Davis (bluesabre) wrote : | #31 |
Attaching debdiff for trusty.
| Changed in exo (Ubuntu Trusty): | |
| status: | Confirmed → In Progress |
|
|
#108 |
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(
fi
;;
|
|
#109 |
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.
| Yetisaurus Akjas (eduard-budai) wrote : | #32 |
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.
My last lines in /usr/share/
X-XFCE-
X-XFCE-
X-XFCE-
|
|
#110 |
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:/
[Risks and why]: This is the opposite of the patch that landed, except for the removal of the mozilla-
[String/UUID change made/needed]: None
|
|
#111 |
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(
-remote 'openURL(
-remote 'openfile(file)'
were verified and are working properly.
|
|
#113 |
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.
|
|
#114 |
(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(
> -remote 'openURL(
> -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(
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(
else
$firefoxpath -P $profile -new-instance $url
fi
Hello David, or anyone else affected,
Accepted exo into trusty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
| 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:/
| Greg (thorn-m) wrote : | #35 |
# 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 : | #36 |
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 |
| Jochen Seidel (x+launchpad) wrote : | #39 |
The proposed package fixed the bug for me.
| tags: |
added: verification-done-trusty removed: verification-needed |
| Ivan Frederiks (idfred) wrote : | #40 |
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 |
|
|
#115 |
Quick update, another thing this broke is the Windows 7 + jump menu:
http://
|
|
#116 |
(In reply to noitidart from comment #69)
> Quick update, another thing this broke is the Windows 7 + jump menu:
> http://
This makes no sense, those are not using -remote: https:/
|
|
#117 |
(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://
>
> This makes no sense, those are not using -remote:
> https:/
> WindowsJumpList
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".
| Launchpad Janitor (janitor) wrote : | #118 |
This bug was fixed in the package firefox - 36.0.1+
---------------
firefox (36.0.1+
* New upstream stable release (FIREFOX_
- 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 |
| Launchpad Janitor (janitor) wrote : | #119 |
This bug was fixed in the package firefox - 36.0.1+
---------------
firefox (36.0.1+
* New upstream stable release (FIREFOX_
- 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 |
|
|
#120 |
Just a note, the documentation should be updated that the feature has been re-included.
https:/
|
|
#121 |
(In reply to haarp from comment #72)
> Just a note, the documentation should be updated that the feature has been
> re-included.
>
> https:/
> remote_
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 "?.?"?
|
|
#122 |
It's in 36.0.1, but it's guaranteed to still be there in 37.
|
|
#123 |
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.
|
|
#124 |
(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.
|
|
#125 |
(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!
|
|
#126 |
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://
it didnt work :(
|
|
#127 |
(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"
|
|
#128 |
(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://
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 :(
|
|
#129 |
(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://
>
> 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 |
|
|
#130 |
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.
|
|
#131 |
(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.
|
|
#132 |
(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.
|
|
#133 |
(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:/
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.
|
|
#134 |
(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".
|
|
#135 |
(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
|
|
#136 |
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.
|
|
#137 |
(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 :)
|
|
#139 |
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 : | #140 |
This bug was fixed in the package exo - 0.10.2-
---------------
exo (0.10.2-
* 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.
|
|
#142 |
(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)
|
|
#143 |
The release notes for 36.0.3 still claim that the -remote option has been removed, even though it now hasn't.
| Changed in exo (Ubuntu): | |
| status: | Confirmed → Fix Released |
This also breaks ubuntu-
Report filed here: https:/
| 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 |
| Mathew Hodson (mathew-hodson) wrote : | #147 |
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 |
| Changed in exo (Debian): | |
| status: | New → Fix Released |


Since Firefox 36.0 -remote is no longer supported [1][2][3], so `exo-open --launch WebBrowser URL` no longer opens URL.
[1] https:/ /developer. mozilla. org/en- US/Firefox/ Releases/ 36#Other /developer. mozilla. org/en- US/docs/ Mozilla/ Command_ Line_Options# -remote_ remote_ command /bugzilla. mozilla. org/show_ bug.cgi? id=1080319
[2] https:/
[3] https:/