DESKTOP_STARTUP_ID breaks -remote openURL

NEW
Unassigned

Status

()

Core
Widget: Gtk
P3
normal
10 years ago
2 years ago

People

(Reporter: Francois Gouget, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+)

(Reporter)

Description

10 years ago
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.
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.
Whiteboard: [CLOSEME 2010-11-01]
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 3

7 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
(Reporter)

Updated

7 years ago
Whiteboard: [CLOSEME 2010-11-01]
Version: unspecified → 4.0 Branch
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.
Status: UNCONFIRMED → NEW
Component: General → Widget: Gtk
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → gtk
Version: 4.0 Branch → Trunk

Comment 5

3 years ago
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.
(Reporter)

Comment 6

3 years ago
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

3 years ago
If the -remote option really is going to be disabled, is there another way to connect to a specific profile instance?
(Reporter)

Comment 8

3 years ago
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

3 years ago
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
(Reporter)

Comment 10

3 years ago
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.)

Updated

2 years ago
Priority: -- → P3
Whiteboard: tpi:+
You need to log in before you can comment on or make changes to this bug.