Closed Bug 267435 Opened 18 years ago Closed 17 years ago

mozilla-xremote-client -a firefox "openurl($url,new-tab)" won't open a new tab.

Categories

(Toolkit :: Startup and Profile System, defect)

1.7 Branch
x86
FreeBSD
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 290782

People

(Reporter: joris, Assigned: benjamin)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041103 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041103 Firefox/1.0RC1

mozilla-xremote-client -a firefox "openurl($url,new-tab)" won't open a new tab
(or anything else for that matter) with the url, this worked fine with 0.10.1.
new-window works fine though.

Reproducible: Always
Steps to Reproduce:
1. start firefox RC1
2. run /usr/X11R6/lib/firefox/lib/firefox-1.0/mozilla-xremote-client -a any
"openurl($url,new-tab)"

Actual Results:  
Nothing happens, that's the issue :)

Expected Results:  
Open a new tab window with $url in firefox wich is allready running.
Version: unspecified → 1.0 Branch
I've got the same exact issue on Linux and Firefox 1.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041117 Firefox/1.0

I have the same problem too. Firefox 1.0 on linux, with both the official
binaries and built from source.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
(Debian package 1.0-2)

I see this too, but *only* when the url specified does not contain a protocol. 
So, firefox -remote 'openURL(www.google.com,new-tab)' does nothing, but firefox
-remote 'openURL(http://www.google.com,new-tab)' works properly.
*** Bug 267635 has been marked as a duplicate of this bug. ***
As a special case of comment #3, mozilla-xremote-client fails silently if the
url given is empty 'openURL(,new-tab)' whereas before firefox1.0 this command
used to open the user's homepage.
This bug is now also present on the trunk since aviary landed (verified with a
nightly build from 10 Dec 2004). Should I open a separate bug for the trunk
version of this bug, or should this bug be moved to Version "Trunk" (with
"aviary-landing" keyword added)?
Based on the time this regressed, it could be that the fixes for bug 172962 and
bug 263689 caused this. Specifically this patch by Dan M (adding to CC)
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=XRemoteService.cpp&branch=&root=/cvsroot&subdir=/mozilla/xpfe/components/xremote/src&command=DIFF_FRAMESET&rev1=1.44&rev2=1.45
Unfortunately, my code-fu is insufficient to verify whether these changes could
indeed have cause this bug. Sorry if I was wrong.
(In reply to comment #3)
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
> (Debian package 1.0-2)
> 
> I see this too, but *only* when the url specified does not contain a protocol. 
> So, firefox -remote 'openURL(www.google.com,new-tab)' does nothing, but firefox
> -remote 'openURL(http://www.google.com,new-tab)' works properly.

This sounds exactly what I've been experiencing.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

One workaround might be(testing now) might be to use the single window mode
prefs to force links from applications into new tabs, and then just open with:
firefox $URL
I'm not sure if this is related, but with Firefox 1.0/1.0.1 the following works:

mozilla-xremote-client -a firefox "openURL(<SOME URL>, new-window)"

but the -p switch for profiles stopped working with 1.0/1.0.1, ie. this fails:

mozilla-xremote-client -a firefox -p myprofile "openURL(<SOME URL>, new-window)"

If I only run one firefox instance with my main profile the first one is of
course OK, but I'm not sure what happens when you have several instances running...
I have the same results as in comment 3:
firefox -remote "openURL(www.mozilla.org, new-tab)"
does nothing, but
firefox -remote "openURL(http://www.mozilla.org, new-tab)"
works as expected.
Likewise :
firefox -remote "openURL(/path/to/some/file.html, new-tab)"
does nothing, but
firefox -remote "openURL(file:/path/to/some/file.html, new-tab)"
works as expected.

I have hacked my firefox 1.0.4 for SuSE Linux to avoid this problem by changing
where it says:

opt="`pwd`/$opt"

to 

opt="file://`pwd`/$opt"


*** This bug has been marked as a duplicate of 290782 ***
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.