desktop-packages team mailing list archive

[Bug Watch Updater <1425972@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 69 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1080319.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2014-10-09T02:16:03+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/0

------------------------------------------------------------------------
On 2014-10-09T02:16:24+00:00 Mh+mozilla wrote:

Benjamin, what do you think?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/1

------------------------------------------------------------------------
On 2014-10-09T02:17:33+00:00 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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/2

------------------------------------------------------------------------
On 2014-10-09T02:25:01+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/3

------------------------------------------------------------------------
On 2014-10-09T08:05:28+00:00 Mh+mozilla wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/4

------------------------------------------------------------------------
On 2014-10-09T09:00:42+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/5

------------------------------------------------------------------------
On 2014-10-09T15:53:34+00:00 Benjamin Smedberg (Mozilla) [:bs] wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/6

------------------------------------------------------------------------
On 2014-10-10T02:13:10+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/7

------------------------------------------------------------------------
On 2014-10-10T02:15:39+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/8

------------------------------------------------------------------------
On 2014-10-13T19:40:35+00:00 Benjamin Smedberg (Mozilla) [:bs] wrote:

Comment on attachment 8502937
Remove the -remote option

\o/

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/9

------------------------------------------------------------------------
On 2014-10-13T22:27:26+00:00 Mh+mozilla wrote:

https://hg.mozilla.org/integration/mozilla-inbound/rev/8044e5199fe2

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/10

------------------------------------------------------------------------
On 2014-10-14T13:44:46+00:00 Cbook wrote:

https://hg.mozilla.org/mozilla-central/rev/8044e5199fe2

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/11

------------------------------------------------------------------------
On 2014-10-15T13:33:13+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/12

------------------------------------------------------------------------
On 2014-10-15T13:35:03+00:00 Hub-g wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/13

------------------------------------------------------------------------
On 2014-10-15T22:29:42+00:00 Mh+mozilla wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/14

------------------------------------------------------------------------
On 2014-10-15T23:32:14+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/15

------------------------------------------------------------------------
On 2014-10-15T23:37:06+00:00 Mh+mozilla wrote:

Is your firefox configured to always show the profile selector?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/16

------------------------------------------------------------------------
On 2014-10-15T23:43:44+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/17

------------------------------------------------------------------------
On 2014-10-16T00:13:34+00:00 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.)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/18

------------------------------------------------------------------------
On 2014-10-18T06:07:15+00:00 Kyle Machulis 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/19

------------------------------------------------------------------------
On 2014-11-04T19:37:48+00:00 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....

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/20

------------------------------------------------------------------------
On 2014-11-04T20:26:52+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/21

------------------------------------------------------------------------
On 2014-11-04T20:39:58+00:00 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...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/22

------------------------------------------------------------------------
On 2014-11-04T21:56:23+00:00 Mh+mozilla wrote:

cf. comment 18.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/23

------------------------------------------------------------------------
On 2014-11-04T23:21:06+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/24

------------------------------------------------------------------------
On 2014-11-04T23:30:16+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/25

------------------------------------------------------------------------
On 2014-12-03T23:12:50+00:00 Sledru wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/26

------------------------------------------------------------------------
On 2015-01-16T04:18:04+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/27

------------------------------------------------------------------------
On 2015-01-16T04:39:16+00:00 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"

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/28

------------------------------------------------------------------------
On 2015-01-16T05:21:22+00:00 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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/29

------------------------------------------------------------------------
On 2015-02-03T21:23:22+00:00 Jmizell wrote:

I can confirm this breaks a similiar use case I have to
lilydjwg@xxxxxxxxx. 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/30

------------------------------------------------------------------------
On 2015-02-12T13:40:00+00:00 Jypenator wrote:

Updated:
https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-remote_remote_command
and
https://developer.mozilla.org/en-US/Firefox/Releases/36#Other

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/31

------------------------------------------------------------------------
On 2015-02-26T07:49:51+00:00 Davide Basilio Bartolini 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 lilydjwg@xxxxxxxxx.
> 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/33

------------------------------------------------------------------------
On 2015-02-28T13:48:03+00:00 Evilpies wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/50

------------------------------------------------------------------------
On 2015-03-01T00:16:15+00:00 Robert Krawitz 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/51

------------------------------------------------------------------------
On 2015-03-02T00:57:39+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/53

------------------------------------------------------------------------
On 2015-03-02T15:35:04+00:00 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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/55

------------------------------------------------------------------------
On 2015-03-02T17:42:36+00:00 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.)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/56

------------------------------------------------------------------------
On 2015-03-02T21:45:56+00:00 Mh+mozilla wrote:

See comment 0, use -new-tab.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/60

------------------------------------------------------------------------
On 2015-03-03T11:45:20+00:00 Carlo de Wolf 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/61

------------------------------------------------------------------------
On 2015-03-03T23:56:29+00:00 Don Barry 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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/62

------------------------------------------------------------------------
On 2015-03-04T09:34:23+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/63

------------------------------------------------------------------------
On 2015-03-04T09:37:24+00:00 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/64

------------------------------------------------------------------------
On 2015-03-04T13:53:44+00:00 Robert Krawitz 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/67

------------------------------------------------------------------------
On 2015-03-04T14:09:47+00:00 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/68

------------------------------------------------------------------------
On 2015-03-04T17:09:11+00:00 Evilpies wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/69

------------------------------------------------------------------------
On 2015-03-04T17:14:36+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/70

------------------------------------------------------------------------
On 2015-03-04T17:33:50+00:00 Evilpies wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/71

------------------------------------------------------------------------
On 2015-03-04T17:40:23+00:00 Sledru wrote:

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

Benjamin, Mike, do you agree? Thanks

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/72

------------------------------------------------------------------------
On 2015-03-04T20:05:20+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/73

------------------------------------------------------------------------
On 2015-03-04T20:57:33+00:00 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().

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/74

------------------------------------------------------------------------
On 2015-03-04T21:47:57+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/75

------------------------------------------------------------------------
On 2015-03-04T21:52:33+00:00 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. :(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/76

------------------------------------------------------------------------
On 2015-03-04T22:45:06+00:00 Kbrosnan-mozilla wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/80

------------------------------------------------------------------------
On 2015-03-05T00:30:44+00:00 Mh+mozilla wrote:

This should do the work:
https://addons.mozilla.org/en-US/firefox/addon/restore-remote/

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/87

------------------------------------------------------------------------
On 2015-03-05T01:00:07+00:00 Robert Krawitz wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/88

------------------------------------------------------------------------
On 2015-03-05T01:16:59+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/89

------------------------------------------------------------------------
On 2015-03-05T01:46:53+00:00 Robert Krawitz wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/90

------------------------------------------------------------------------
On 2015-03-05T01:55:48+00:00 Don Barry 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/91

------------------------------------------------------------------------
On 2015-03-05T02:00:37+00:00 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 :(

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/92

------------------------------------------------------------------------
On 2015-03-05T02:08:24+00:00 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/93

------------------------------------------------------------------------
On 2015-03-05T02:23:14+00:00 Robert Krawitz 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/94

------------------------------------------------------------------------
On 2015-03-05T03:24:02+00:00 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
	;;

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/95

------------------------------------------------------------------------
On 2015-03-05T03:36:41+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/96

------------------------------------------------------------------------
On 2015-03-05T09:32:31+00:00 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/98

------------------------------------------------------------------------
On 2015-03-05T09:44:06+00:00 Mh+mozilla wrote:

https://hg.mozilla.org/releases/mozilla-release/rev/1bf1bdefeae0

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/99

------------------------------------------------------------------------
On 2015-03-05T16:42:44+00:00 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/100

------------------------------------------------------------------------
On 2015-03-05T17:13:22+00:00 Greg Klanderman 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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/101

------------------------------------------------------------------------
On 2015-03-05T17:19:38+00:00 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1425972/comments/102


** Changed in: firefox
       Status: Unknown => Fix Released

** Changed in: firefox
   Importance: Unknown => Medium

** Bug watch added: Python Roundup #23262
   http://bugs.python.org/issue23262

** Bug watch added: Mozilla Bugzilla #1133731
   https://bugzilla.mozilla.org/show_bug.cgi?id=1133731

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to emacs24 in Ubuntu.
https://bugs.launchpad.net/bugs/1425972

Title:
  Firefox no longer supports -remote parameter

Status in exo:
  Fix Released
Status in The Mozilla Firefox Browser:
  Fix Released
Status in One Hundred Papercuts:
  Confirmed
Status in emacs24 package in Ubuntu:
  Confirmed
Status in exo package in Ubuntu:
  Confirmed
Status in firefox package in Ubuntu:
  Fix Released
Status in emacs24 source package in Trusty:
  Confirmed
Status in exo source package in Trusty:
  Fix Committed
Status in firefox source package in Trusty:
  Confirmed
Status in emacs24 source package in Utopic:
  Confirmed
Status in exo source package in Utopic:
  In Progress
Status in firefox source package in Utopic:
  Confirmed
Status in exo package in Debian:
  New

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 - langpack-en-ZA@xxxxxxxxxxxxxxxxxxx
   English (GB) Language Pack - langpack-en-GB@xxxxxxxxxxxxxxxxxxx
   Français Language Pack - langpack-fr@xxxxxxxxxxxxxxxxxxx
   Deutsch (DE) Language Pack - langpack-de@xxxxxxxxxxxxxxxxxxx
   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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/exo/+bug/1425972/+subscriptions