Closed Bug 246168 Opened 20 years ago Closed 20 years ago

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

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: daihardM3, Assigned: bryner)

References

Details

Attachments

(3 files)

A working script
300 bytes, text/plain
Details
The script I use. It can open files from the command line.
373 bytes, text/plain
Details
Fix the firefox start script to dealwith -remote
346 bytes, patch
Details | Diff | Splinter Review 
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
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.
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?
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.
Also broken in 0.9 (final)
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.
Bug 246166 looks similar.
(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.
(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".



(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+
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

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?
*** Bug 246951 has been marked as a duplicate of this bug. ***
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
> 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".
> 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?
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. :-/
(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?
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.
(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)"

(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.
Attached file 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.
*** Bug 247393 has been marked as a duplicate of this bug. ***
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.
(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)
(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).


*** Bug 247120 has been marked as a duplicate of this bug. ***
Blocks: 177996
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
Closed: 20 years ago
Resolution: --- → INVALID
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)
> -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 ;)
(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.
(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.
(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.
(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.
(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


(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.

 


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.
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.
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.
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.
Flags: blocking-aviary1.0?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: