478951 - DESKTOP_STARTUP_ID breaks -remote openURL

Status: NEW

(Core :: Widget: Gtk, defect, P3)

Description

[Francois Gouget]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6

If DESKTOP_STARTUP_ID is set, by KDE for instance, then '-remote openURL' does not work anymore and gives the following error:

Error: Failed to send command: 500 command not parseable

The DESKTOP_STARTUP_ID usage is part of the startup notification specification:
http://standards.freedesktop.org/startup-notification-spec

This bug happens no matter what DESKTOP_STARTUP_ID is set to. However for reference, here's a typical value set by KDE 3.5:
DESKTOP_STARTUP_ID="ubuntu804;1234881277;857221;28287_TIME37444154"

I verified that this bug is present in both Firefox 3.0b5 and 3.0.6.


Reproducible: Always

Steps to Reproduce:
In a shell type the following:
firefox &
# Wait for firefox to start
DESKTOP_STARTUP_ID=1 firefox -remote "openURL(http://www.mozilla.org)"
Actual Results:  
The following error message and a non-zero exit code:

Error: Failed to send command: 500 command not parseable


Expected Results:  
A new window or tab in Firefox, no error message and zero as the exit code.

Comment 1

[Tyler Downer [He/Him]]

This is a mass search for bugs which are in the Firefox General component, are
UNCO, have not been changed for 500 days and have an unspecified version. 

Reporter, can you please update to Firefox 3.6.10 or later, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the issue, please update this bug. If the issue is gone, please set the status to RESOLVED > WORKSFORME.

Comment 2

[Tyler Downer [He/Him]]

No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.

Comment 3

[Francois Gouget]

I have retested this with Firefox 3.6.16 as shipped in Ubuntu 10.10, after deleting '~/.mozilla' to wipe out the old profile, and the bug is still present, exactly as originally described.

I then downloaded Firefox 4.0, again wiped out ~/.mozilla, and retested. The bug is still present in Firefox 4.0, exactly as originally described.

Comment 4

[Karl Tomlinson (:karlt back Feb 10)]

Remote protocol seems to work when using
DESKTOP_STARTUP_ID=1 firefox http://www.mozilla.org
so apparently this is something different in the path used with an explicit -remote.

Comment 5

[Ancoron]

I am currently on Firefox 38 using the Ubuntu 15.04 package, running the KDE Plasma 5 desktop and I am still affected by this.

While "-remote" invocations work fine in shell scripts executed inside a terminal, they always fail when executed from inside an application.

As I need the "-remote" because I need to target a specific profile instance, this is a show-stopper for me.

Comment 6

[Francois Gouget]

I am surprised that -remote works with Firefox 38 as that option is supposed to have been removed / disabled in Firefox 36:
https://bugzilla.mozilla.org/show_bug.cgi?id=1080319

Comment 7

[Ancoron]

If the -remote option really is going to be disabled, is there another way to connect to a specific profile instance?

Comment 8

[Francois Gouget]

At least in Iceweasel 31.6.0esr-1 as packaged by Debian, the -remote option and this bug are still present.

But in Firefox 38.0.1 the -remote option is no longer present and running a command like the one below works fine:
   DESKTOP_STARTUP_ID=1 firefox http://www.mozilla.org

So this bug can probably be closed.

Comment 9

[Ancoron]

OK, if the -remote option is no longer present, how do I instruct a specific instance to open a URL then?

The simple command without a profile only opens the URL in the first started instance, no matter which profile that instance is actually running. This is unacceptable for me, which is why I came to this bug after some struggling and searching.

My actual use case is documented here:
https://support.mozilla.org/en-US/questions/1062423

Comment 10

[Francois Gouget]

This bug is however not about the removal of the -remote option. So this question should rather be asked either in a new bug, or in the bug I mentioned above, bug 1080319.
(Also I have no idea what the answer to your question is.)