'-remote "openURL(<url>, new-tab)"' no longer works

RESOLVED INVALID

Status

()

Toolkit
Startup and Profile System
--
major
RESOLVED INVALID
13 years ago
9 years ago

People

(Reporter: Dai Toyama, Assigned: Brian Ryner (not reading))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040609 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040609 Firefox/0.8.0+ (daihard: XFT+GTK2; opt. for P4/SSE-2)

Running firefox with the "-remote" option as follows should open the URL in a
new tab of the existing Firefox window on Linux.

firefox -remote "openURL(http://www.apple.com, new-tab)"

That, for instance, should open Apple's web site in a new tab of the existing
Firefox window. Instead, however, it pops up the Profile Manager UI.

Reproducible: Always
Steps to Reproduce:
1. Start Firefox normally (i.e. with no paremeter).
2. Start Firefox from the terminal window as follows:
    firefox -remote "openURL(http://www.apple.com, new-tab)"
3. See the Profile Manager UI pop up.

Actual Results:  
Apple's Web site should open in a new tab of the existing Firefox window (opened
in step 1 above).

Expected Results:  
The Profile Manager UI pops up, preventing any further action.
Assignee: bsmedberg → bryner
(Reporter)

Comment 1

13 years ago
In the above report, I entered wrong descriptions on "actual" and "expected"
results. They should have been the other way 'round. Sorry for the confusion.

Comment 2

13 years ago
I have the same problem with firefox 0.9rc.


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+


Sometimes it tries to start up a new instance of the browser, other times i get:

~@wrx% firefox -remote 'openurl("http://www.umich.edu/")'
Error: No running window found

or with an old mozilla:

~@wrx% /usr/bin/mozilla -remote !$
/usr/bin/mozilla -remote 'openurl("http://www.umich.edu/")'
Failed to send command.
Flags: blocking0.9?

Comment 3

13 years ago
I have this problem too. It worked in 0.8, it broke in 0.9RC1.

Here's the command that no longer works:
$ /usr/local/firefox-0.9rc1/firefox -remote 'openURL('http://www.bbc.co.uk/',
new-tab)'
Error: No running window found

I am prompted to select a profile.

This breaks my use of htmlview (which any apps that require a hardcoded browser
use) since the already open browser window cannot be used.

Comment 4

13 years ago
Also broken in 0.9 (final)
(Reporter)

Comment 5

13 years ago
I've found a workaround. Instead of the old one, you can use the following
command  to get it to work:

$ firefox -a firefox -remote openURL(<url>, new-tab)

The "-a firefox" is the new part. I've been told of this on a Firefox forum. I
am not sure of its implication, though. Are they in the middle of reorganising
the command-line options?

I'd still consider it a mere workaround, in any case.

Comment 6

13 years ago
Bug 246166 looks similar.

Comment 7

13 years ago
(In reply to comment #5)

firefox -a firefox -remote "openURL(http://url, new-tab)"
responce is
Error: Failed to send command: 509 internal error

FF 0.9rc
Without new-tab or new-window it opens in existing tab. That's better bun not so.
(Reporter)

Comment 8

13 years ago
(In reply to comment #7)
> (In reply to comment #5)
> 
> firefox -a firefox -remote "openURL(http://url, new-tab)"
> responce is
> Error: Failed to send command: 509 internal error

That's interesting. I wonder if it makes any difference that I specify the full
path to firefox in my shell script to run it, as follows:

$FX_FULLPATH -a firefox -remote "openURL($@, new-tab)"

where $FX_FULLPATH is "/home/dtoyama/firefox/firefox".


Comment 9

13 years ago
(In reply to comment #8)

> $FX_FULLPATH -a firefox -remote "openURL($@, new-tab)"

There is no difference with full path, run from it's dir, error 509 anytime

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040608 Firefox/0.8.0+

Comment 10

13 years ago
in version Firefox 0.9 GTK2+XFT for Linux --remote doesn't work anymore, but in
version 0.8 still work.

 USER AGENT: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615
Firefox/0.9 runnig on Linux Mandrake 10 Cooker
 
 Reproducible: Always
 Steps to Reproduce:
 [roberto@wsraf roberto]$  /usr/local/firefox/firefox 
 [roberto@wsraf roberto]$  /usr/local/firefox/firefox --remote
"openurl(about:blank, new-tab)"
Error: No running window found

 WORKAROUND: use this
 /usr/local/firefox/firefox -a firefox --remote "openurl(about:blank, new-tab)"

 Cheers,
 /roberto

Comment 11

13 years ago
I get either the "Error: Failed to send command: 509 internal error" or the
profile manager when using the listed workaround. I get the 509 error from the
command line when typing out:

/pathto/firefox -a firefox -remote "openurl(http://www.cnn.com, new-tab)"

I get the profile manager when launching Firefox from the same script I've been
using since roughly .6 with the addition of the -a firefox:


#!/bin/bash
URL=$*

firefox_running()
{
/usr/local/firefox/firefox -a firefox -remote "openurl($URL, new-tab)"
}
firefox_new()
{
/usr/local/firefox/firefox $URL
}

STR=`/usr/local/firefox/firefox -remote "ping()" 2>&1 | grep No`
if [[ "$STR" == "Error: No running window found" ]]; then
firefox_new;
else
firefox_running;
fi
Confirmed, with Dai Toyama's 0.9-equivalent Linux build.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
(daihard: XFT+GTK2; opt. for P4/SSE-2)

I also get an Error 509 message, especially if I use the proposed Linux start
script found in bug 177996 comment 79.

However, because 0.9 is released, switching to blocking1.0?.
Flags: blocking0.9? → blocking1.0?

Comment 13

13 years ago
*** Bug 246951 has been marked as a duplicate of this bug. ***

Comment 14

13 years ago
It's all about the *SPACE* between the comma and the command after the url.

So this works:

./firefox -a firefox -remote "openURL(http://www.slashdot.org,new-window)"

and this doesn't:

./firefox -a firefox -remote "openURL(http://www.slashdot.org, new-window)"

The "-a firefox" part is now necessary though.

Best regards,

Bas

Comment 15

13 years ago
> It's all about the *SPACE* between the comma and the command after the url.
>
> So this works:
> 
> ./firefox -a firefox -remote "openURL(http://www.slashdot.org,new-window)"

That does work, but I get a new tab, even when using "new-window".

Comment 16

13 years ago
> It's all about the *SPACE* between the comma and the command after the url.

Cool, that fixes the "509 internal error" when typing out the command from the
commandline, unfortunately I'm still seeing the profile manager when using the
script listed above. I know it's ugly, but it worked for years. Anyone care to
point out the flaw?

Comment 17

13 years ago
In the grand tradition of needing to point out my ignorance publicly before
seeing a solution to a problem I see where I screwed up... For those following
at home this works:

#!/bin/bash
URL=$*

firefox_running()
{
/usr/local/firefox/firefox -a firefox -remote "openurl($URL,new-tab)"
}
firefox_new()
{
/usr/local/firefox/firefox $URL
}


STR=`/usr/local/firefox/firefox -a firefox -remote "ping()" 2>&1 | grep No`
if [[ "$STR" == "Error: No running window found" ]]; then
firefox_new;
else
firefox_running;
fi


I had failed to add the '-a firefox' in the check for a running copy. :-/
(Reporter)

Comment 18

13 years ago
(In reply to comment #14)
> It's all about the *SPACE* between the comma and the command after the url.
> 
> and this doesn't:
> 
> ./firefox -a firefox -remote "openURL(http://www.slashdot.org, new-window)"

Not the case with me. My script has the following line that WORKS:

/home/dtoyama/fx/firefox -a firefox -remote "openURL($@, new-tab)" 

where $@ is the input URL.

> The "-a firefox" part is now necessary though.

That's what needs to be fixed, or at the very least explained. The old syntax
has worked fine, why change it?

Comment 19

13 years ago
This workaround should be mentioned on this page:

http://www.mozilla.org/unix/remote.html

ASAP, as it seems to be the "official" source of information about how to get
this stuff working under Linux/Unix.  Additionally, it would be nice if it
talked about the differences between Netscape,Mozilla & Firefox.

Comment 20

13 years ago
(In reply to comment #7)
> (In reply to comment #5)
> 
> firefox -a firefox -remote "openURL(http://url, new-tab)"
> responce is
> Error: Failed to send command: 509 internal error
> 
> FF 0.9rc
> Without new-tab or new-window it opens in existing tab. That's better bun not so.

Actually it will work if you remove the space after the comma and before the
"new-tab" option. It should look as follows:
firefox -a firefox -remote "openURL(http://url,new-tab)"
(Reporter)

Comment 21

13 years ago
(In reply to comment #20)
> Actually it will work if you remove the space after the comma and before the
> "new-tab" option. It should look as follows:
> firefox -a firefox -remote "openURL(http://url,new-tab)"

Please see #18. I have a space between the URL and "new-tab" but the command
works fine.

Comment 22

13 years ago
Created attachment 151145 [details]
A working script

I picked the script mentioned above and tweaked it a bit. I'm using it as the
default browser in Gnome and it works ok. I guess something like this should go
into the "official" firefox script.

Comment 23

13 years ago
*** Bug 247393 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 24

13 years ago
I've just noticed that the old syntax as below works with the TRUNK builds:

$ firefox -remote "openURL(<url>, new-tab)"

It means that if this is going to be fixed, the reference is right in the TRUNK.

Comment 25

13 years ago
(In reply to comment #24)
> I've just noticed that the old syntax as below works with the TRUNK builds:
> 
> $ firefox -remote "openURL(<url>, new-tab)"
> 
> It means that if this is going to be fixed, the reference is right in the TRUNK.

trrunk builds seems to be 0.8 based and not 0.9 (they look for their profile in
$HOME/.firefox)
(Reporter)

Comment 26

13 years ago
(In reply to comment #25)
> trunk builds seems to be 0.8 based and not 0.9 (they look for their profile in
> $HOME/.firefox)

Yes, the dev trunk is currently based upon 0.8.0+. They will merge the new 0.9
features back into the trunk sometime in the future. One of the backports is the
profile location. As of 2004-06-18, the trunk build uses the same profile
location as the branch ($HOME/.mozilla/firefox).

Comment 27

13 years ago
*** Bug 247120 has been marked as a duplicate of this bug. ***

Comment 28

13 years ago
Created attachment 151958 [details]
The script I use. It can open files from the command line.

Updated

13 years ago
Blocks: 177996
Created attachment 151973 [details] [diff] [review]
Fix the firefox start script to dealwith -remote

This fixes the 0.9/0.9.1 firefox script so that it deals with remote.
okay, where to start with this one...

-remote "openURL(foo, new-tab)" (note the space) is still busted on aviary
branch, its on my list of 1.8a fixes to backport.

-remote <anything> doesn't work now unless invoked with -a firefox -remote
<anything>.  This is necessary to differentiate between different xremote
clients (tbird, suite, etc)

anything besides that is covered under bug 177996

as reported, this bug is invalid since the command syntax has changed to support
multiple apps.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID

Comment 31

13 years ago
Why this bug is resolved as invalid?
If the syntax change, it has to be documented somewhere eg. at least at:
http://www.mozilla.org/unix/remote.html

And it is not. Also 
firefox --help command should provide accurate info about proper syntax.

Please reopen it 'cause it's not invalid. Ivalid is everything about execution
of firefox 0.9 not this bug itself.

thanks,
-daniel
right, those are actually bugs.  Someone needs to file those two bugs in the
appropriate places.  (One bug for the web site documentation, and one bug for
fixing firefox --help).  At this point, 30 comments in, its way too late to
morph the bug into something useful, so we resolve as invalid and file a bug
about the actual issue.

The latter is true for more than just this issue.  Heck, we still list
--splash... (yes, that's my bug, yes, I'm going to fix it soon)

Comment 33

13 years ago
> -remote <anything> doesn't work now unless invoked with -a firefox -remote
> <anything>.  This is necessary to differentiate between different xremote
> clients (tbird, suite, etc)

Why do you have to run "firefox -a firefox -remote ..."?  It seems to me that
firefox should default to "-a firefox", thunderbird should default to "-a
thunderbird", etc.  Not just for backwards compatibility, but also for sanity ;)

Comment 34

13 years ago
(In reply to comment #33)
> > -remote <anything> doesn't work now unless invoked with -a firefox -remote
> > <anything>.  This is necessary to differentiate between different xremote
> > clients (tbird, suite, etc)
> 
> Why do you have to run "firefox -a firefox -remote ..."?
Because, simply it doesn't work  (Using RH FC1, FireFox0.9)

>  It seems to me that
> firefox should default to "-a firefox",
Maybe shuld, but it doesn't

> thunderbird should default to "-a
> thunderbird", etc.  Not just for backwards compatibility, but also for sanity ;)


well, could someone explain to me, whay all bugs about firefox execution are
marked invalid? If definitely they are real/valid ugly bugs?

thanks
-dan
this bug is NOT valid.  I gave two examples of valid bugs that need to be fixed.

Jesse, that's a good question, you'd have to ask blizzard why it works that way.  

Once bug 177996 is resolved, it'll be a mostly moot point, except for people who
want to roll their own startup script, which is why the two bugs I mentioned
need to be fixed.  That should be _soon_ if I can finish other stuff.

As for "all bugs about Firefox execution being resolved invalid" I have no idea
what you're talking about.  This particular bug is invalid, because its saying
that invalid syntax doesn't work, which is as intended.  The missing
documentation is the bug here, but the length of the comments makes morphing
impractical.

Comment 36

13 years ago
(In reply to comment #35)
bug 177996 is resolved, it'll be a mostly moot point, except for people who
> want to roll their own startup script, which is why the two bugs I mentioned
> need to be fixed.  That should be _soon_ if I can finish other stuff.

Not only this, but all exterior programs using old mozilla API for launching
firefox (like (x)emacs, urlview from mutt) now fail...

IMO, that's a necessary evil.  The old API didn't understand multiple
mozilla-based apps, so if mozilla and firefox were both open, it almost seemed
random as to which one opened the link.

Apps that use the GNOME default browser setting will be fine, since we'll be
able to do something like "firefox %s" (i.e. my fedora install uses "mozilla %s")

its pre-1.0 software, command-line options are subject to change.

Comment 38

13 years ago
(In reply to comment #37)
> IMO, that's a necessary evil.  The old API didn't understand multiple
> mozilla-based apps, so if mozilla and firefox were both open, it almost seemed
> random as to which one opened the link.
> 
> Apps that use the GNOME default browser setting will be fine, since we'll be
> able to do something like "firefox %s" (i.e. my fedora install uses "mozilla %s")
> 

But GNOME is not a solution, many people refuse to use GNOME or to use something
based on theis model of obsolete and bloated UI.

If firefox goes to a gnome app, then its a losing situation.
I'd pay for Opera rather than using gnome, kde or some other heavy limited
environment.
well, Firefox is moving closer and closer to GNOME integration, so you might
have issues.

in any case, just change the relevant apps to use "firefox %s" instead.  And if
the app hardcodes it, bug the app author to upgrade that.  If an app (i.e.
Xchat) hardcodes mozilla -remote X and you have just Tbird open, or opened
Firefox second, you're in trouble with the old API anyway.

Comment 40

13 years ago
(In reply to comment #39)
> well, Firefox is moving closer and closer to GNOME integration, so you might
> have issues.


Bad news, *very* bad news I'll say it would be *major* bug. IE with windows,
firefox with gnome, and for whose who do not like thins kind of UI nothing...
Since there's already galeon and epyphany I do not see the point of it. In any
case I'll *never* use something needing a libgnome*, and I'll nfiight, theis
restriction of my freedom not to use a "desktop".


> in any case, just change the relevant apps to use "firefox %s" instead.  And if
> the app hardcodes it, bug the app author to upgrade that.

Where is the doc of the new API, so I can send it in the bug report ?
firefox -help still refers to http://www.mozilla.org/unix/remote.html

>  If an app (i.e.
> Xchat) hardcodes mozilla -remote X and you have just Tbird open, or opened
> Firefox second, you're in trouble with the old API anyway.

Where is this new API defined ? And how can I specify new tab or new window ? Or
open a new window but without giving a specific URL (xfeDoCommand(openBrowser)
in old API).

(In reply to comment #40)
> (snip comments based on not reading the previous comments)

if you'd read earlier comments you'd know that they're not documented.  Someone
should file the appropriate bugs.

As for requiring libgnome*, I don't think we'll fail without it, but GTK2 builds
are going to start looking for certain things like stock images etc.  More and
more, we're becoming closely integrated with the GNOME environment (theme, shell
interfaces, etc).  This is "the way it is" and you can kick and scream all you
want, but that's the direction we've decided to go as a project.

Comment 42

13 years ago
(In reply to comment #41)

> are going to start looking for certain things like stock images etc.  More and
> more, we're becoming closely integrated with the GNOME environment (theme, shell
> interfaces, etc).  This is "the way it is" and you can kick and scream all you
> want, but that's the direction we've decided to go as a project.

Ok, so I can befgin looking for another browser and telling people I know they
should do the same.

For me Gecko is dead tonight
(In reply to comment #42)
> Ok, so I can begin looking for another browser and telling people I know they
> should do the same.
> 
> For me Gecko is dead tonight

Stop trolling.

Providing closer integration with GNOME libraries and GNOME artwork *IS* *NOT*
the same as dumping IE wholesale into Windows. As you just mentioned, you can
STILL USE Galeon or Epiphany with GNOME and have a reasonable expectation of
making it work right. You don't have that with IE.

I suggest you go and reread the above comments more closely. I also suggest you
realize that your comments are inaccurate and inflammatory.

/finis

Comment 44

13 years ago
(In reply to comment #43)
> 
> Stop trolling.
>

I'm *not* trollinG.
> Providing closer integration with GNOME libraries and GNOME artwork *IS* *NOT*
> the same as dumping IE wholesale into Windows. 

It is. It is making the browser part of a system whose oal is to control the
global UI. Which I do not want since I consider this UI as lerely unusable.

>As you just mentioned, you can
> STILL USE Galeon or Epiphany with GNOME and have a reasonable expectation of
> making it work right. You don't have that with IE.

And what will I be able to use *without* GNOME ?

I do not want of GNOME. I consider it is based on a complete error.
And I see that I am refused the freedom not to use it.

You choose to make firefox a part oàf gnome. Irefuse gnome, so I consider
firefox is no more a valid browser for me.

 

Comment 45

13 years ago
You seem to be completely unaware of what integration means. Integration means
cooperation with the environment, and the environment is GNOME in this case.
This doesn't mean that you will have to run GNOME to be able to use Firefox,
which happens to integrate with it.

And as for not wanting to use any app that uses part of GNOME, well, sorry but
GTK2 is a part of GNOME, is developed with GNOME in mind, and now has stuff that
used to be in libgnomeui (at least). It's not like Firefox is going to depend on
bonobo or some of that deep-GNOME stuff.

And if it does get to the point of depending on more than just GTK2, I believe
it is because it needs to do so, and it is for the best, the free *nix desktop
will go nowhere without integration. This doesn't stop you from using Fluxbox or
something like that, just like no one stops you from running Konqueror with GNOME...

Sorry for the rant, I'm not a Firefox developer but I feel that this "I want a
lightweight system at the expense of usability and everyone else's needs" to be
just plain stupid.

Comment 46

13 years ago
Guys, please take this to the forums.  There are 16 people receiving mail on
this because of votes, and another 50-100 or so receiving mail on this because
of being CC'd.  This is violating most if not all of the bugzilla etiquette rules.

Sorry to everybody else for more bugspam.

Comment 47

13 years ago
Filed bugs on the remark in comment #32.
Website http://www.mozilla.org/unix/remote.html fix : bug 249515
Firefox --help fix : bug 249516

Thank you.

Comment 48

13 years ago
Sorry - perhaps I'm wrong here.
But at least my problem is related.

Using thunderbird and firefox in a fluxbox UI.
The script firefox -a firefox --remote "(foo,bar)" works from commandline.
Fine.
From thunderbird, calling this script to open a link in a mail, a
'Save'-Info-Window pops quickly up, then the 'choose-profile'-Dialog opens.

Integration is the wrong way!
Modularisation would be right.

Updated

13 years ago
Flags: blocking-aviary1.0?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.