Closed Bug 177996 Opened 22 years ago Closed 20 years ago

Better Start Script for Firefox

Categories

(Toolkit :: Startup and Profile System, defect, P2)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.7.4

People

(Reporter: scot.hale, Assigned: bryner)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0, Whiteboard: [have patch])

Attachments

(5 files, 17 obsolete files)

diff of the patch above
5.96 KB, patch
Details | Diff | Splinter Review
Patch for previously proposed script to remove bash-specifics
1.40 KB, patch
Details | Diff | Splinter Review
Complete bash-free script
6.49 KB, text/plain
Details
patch against cvs
4.62 KB, patch
bryner
: review+
chofmann
: approval-aviary+
Details | Diff | Splinter Review
one-liner for my issue
271 bytes, patch
bryner
: review+
chofmann
: approval-aviary+
Details | Diff | Splinter Review 
(On RedHat 8.0 KDE 3.0 Phoenix 0.4)

When I open Phoenix the first time it will work fine (uses the default profile
automatically).  Then when I open the second instance, I have to select a
different (and originally create) user profile.  I can not use the same profile
that is being used by the other instance of phoenix.  My friend noted that he
had the same problem with Mozilla.
    I just have a shortcut that runs the phoenix binary each time I launch it. 
Is there a way I can make it so it doesn't ask for a new profile?
I can duplicate this but that's irrelevant because this is not a bug. Why are
you trying to run two instances of Phoenix of Mozilla in the first place? Just
open a new window or tab. KDE will even allow you to have a Phoenix window open
on each virtual desktop.

The reason that two instances cannot use the same profile is because both would
be trying to write to the same files, so to prevent this it is locked out; take
a look at the contents of your .phoenix/default/xxxxxxxx.slt directory when
Phoenix is running. Many other apps do this; off the top of my head licq does,
as does CDBakeOven, etc.

INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
    The user should at least be given the choice to use the same profile when
trying to open the second window.  Whether that is running under the first
instance or not doesn't matter.  
    I can see your point, maybe a user should be tied to many profiles, not just
one profile.  But this doesn't make any sense to a linux newb that is use to
opening any number of instances in windows.  Or even to a developer like me who
has used Linux for quite a while.  

(p.s. I like Phoenix, that is why I am logging this bug, I just want it to be as
user friendly as possible :)

REOPENED
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
The most that could possibly come of this is that the Alert that pops up gives
you the option to open a new window from the running instance, which is maybe
what you were talking about in comment 2?. That would make this an RFE and not a
true bug (the summary would also have to be changed quite a bit). I don't think
that is too likely nor do I think that would be a productive use of resources.

If I don't reINVALID or WONTFIX this then Asa or one of the developers almost
assuredly will.


André,
what do you think?
See bug 76431. WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
James,
    That would solve the problem I am having.  Or possibly there could be a
command line option like (phoenix -use_current_instance_if_it_exists), which
would also solve the problem.  
    How difficult do you think this would be to implement as an RFE?  I noticed
you said you "don't think that is too likely nor do I[you] think that would be a
productive use of resources", which means there are probably bigger fish to fry
at the moment.  In that case could I put it on a low priority TODO list or Wish
List somewhere?
Scot,

It's simply not going to happen. There will always be something more pressing to
fix or do. I very much doubt that it would get in even if you wrote a patch for
it, which is the ONLY way that an RFE of this nature (platform-specific for a
non-issue to most users) would have even a remote chance of getting into Phoenix
(or Mozilla for that matter).

I realize this is an even stronger statement than the one I made in comment 3; I
just want to make it clear how very unlikely this is. It simply won't happen. Sorry.
Here is a script that solved the problem for me, in case anybody reads this bug.
(thank you for responding to my questions James and Andre :)

#!/bin/sh
# author - David Patton

if [[ `ps -e | grep phoenix` ]]
then
        #Mozilla is probably running
        `/usr/local/phoenix/phoenix -remote 'openURL('www.google.com', new-tab)'`
else
        #Mozilla isn't running
        `/usr/local/phoenix/phoenix &`
fi
Now that we have a better understanding of the problem why don't we reopen this?
 It sounds like the launching script just needs to be modified.  A suggestion
has been also posted at http://www.mozillazine.org/forums/viewtopic.php?t=4494
this script will read from the command line so:
pho www.yahoo.com will either open a tab to www.yahoo.com or start phoenix at
www.yahoo.com if it isn't already open:

#!/bin/bash

/opt/phoenix/phoenix -remote "openURL($@, new-tab)" ||
        exec /opt/phoenix/phoenix "$@";
Can you generalize that so that the path to Phoenix is not hardcoded?  Perhaps
something to patch the launching script itself.
Reopenning (David eats his own words)
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
This is based on a script hack on the MozillaZine thread listed in an earlier
comment.

By and large it works, with the exceptional case where:
-Mozilla mail is running, and
-Phoenix is running (script still works fine here); and
-one tries to open another Phoenix window

In this case, a Mozilla browser window will open instead.

If you try to open a Phoenix window again you will this time get a Phoenix
window.

I hope that wasn't too confusing.
--> Confirming as New
--> Summary changed from "asked for a new profile each time a new instance is
opened." to "Profile manager appears when trying to launch a second window in Linux"
URL: http://www.mozillazine.org/forums/vie...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: asked for a new profile each time a new instance is opened. → Profile manager appears when trying to launch a second window in Linux
Sorry for the bugspam. The component is not general but build-config.
Reassigning (hopefully) to bryner.

Also, see bug 122698, which is the equivalent Mozilla bug.
Assignee: blaker → bryner
Component: General → build-config
Patch v0.1b is not really *better* than 0.1 described in comment 12, but it is
cleaner than the first one (no use of ps, grep or wc). That's why I didn't call
it "Patch v0.2"...

It has the advantage of opening the specified URL (if any) in the new window.

It has the same, even bigger, limitation : when mozilla or mozilla-mail is
opened, the new window will be a mozilla window and not a phoenix window. This
patch will **always** open a mozilla window if mozilla is running, even the
first time. So don't use it if you plan to use mozilla, too... 

Please see bug 170609 for the reason of this bad behaviour.
This bug definitely depends on fixing bug 170609. Once that is accomplished it
should not be too hard to build a patch based on the ones already here, assuming
that bug 170609 doesn't fix both problems at once.

-->Depends on bug 170609
Depends on: 170609
when/if bug 122698 gets fixed, it will fix this bug as well (phoenix and mozilla
use the same startup script).  it uses a somewhat more elegant xremote "ping" to
see if an existing process is running.  it also does not treat commandline
options "-something" as URLs (particularly important for something like "-P
profilename" or "-ProfileManager").

Also, FYI, patches should be created with "diff -u"
Fixing patch format, sorry guys.
Attachment #112210 - Attachment is obsolete: true
*** Bug 209625 has been marked as a duplicate of this bug. ***
I'm planning some upcoming X-Remote work that may affect the way this should be
implemented.  -> 0.7.
Target Milestone: --- → Firebird0.7
http://hometown.aol.com/alka1/ProMag.html
Trying to access this URL causes Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.5a) Gecko/20030626 to open a profile window.
Hm, did you know that you can build it single profile...
Target Milestone: Firebird0.7 → Firebird0.8
QA Contact: asa
Darin and I were discussing some changes to the start script to make an existing
instance automatically be used unless a profile option was explicitly used. Not
gonna make 0.8 though.
Target Milestone: Firebird0.8 → Firebird0.9
If Firebird is not running it just starts Firebird. If Firebird is running it
opens a new window.
Attached patch Patch to current launch script (obsolete) — — Splinter Review 
True bug or not, I believe that this behavior acts contrary to what the user
would expect. Here is my patch to browser/app/mozilla.in, so that the launch
script will do all it currently does, plus this.

I got this from my installation of Mozilla 1.4.1 on Fedora Core 1. It acts the
way I expect it to, which is to open a new window rather than ask for another
profile.

I've tested this on my personal machine and it works.
I've just applied that patch then rebuilt Firebird and it made no difference. I
still get the profile manager if I click on a link in Thunderbird. There must be
some other variable defined on your system that isn't set on Mandrake 9.1

My mistake; there is apparently much more involved here than I thought.
well, that patch explicitly only opens a new window if no url (or any other
parameter for that matter) is given on the commandline. hence, comment 26's
behaviour is expected.
*** Bug 231625 has been marked as a duplicate of this bug. ***
Thank you for taking the time to review this bug guys it has been bothering me
for some time but not enough to attempt to defend it in court here. I would love
to see firebird open a new window when it is currently loading the profile
manager. In fact considering the difficulty to directly access the profile
manager and the decreasingly necessary nature of its features (users instead) i
might even suggest removing the capability to and extension if that is possible.
I just dont think that the average user will be looking for its functionality.
Regardless thank you for attempting to fix this little issue.
-Michael
Flags: blocking0.9?
*** Bug 227492 has been marked as a duplicate of this bug. ***
I observe this in Windows as well, so perhaps someone should change the OS.

One instance of this in particular that really ought to be fixed is the problem
of Thunderbird URL integration. The following set of steps (quite common in my
opinion) causes the profile manager to come up:

Launch Thunderbird, click on a URL. This launches Firefox, all is ok.
Click on another URL. This switches to Firefox, all is ok.
Close Firefox. Still all ok. 
Run Firefox via Quicklaunch icon. Works fine.
Click on another URL in a message in Thunderbird. Up pops the profile manager.

Presumably this could technically be considered a bug in Thunderbird. Depends on
how you look at it. Should I enter a bug there instead?
This is a linux bug and not Mozilla.
File it as Firebird bug
*** Bug 238984 has been marked as a duplicate of this bug. ***
Blocks: 240696
No longer depends on: 170609
Flags: blocking0.9? → blocking0.9+
Moving over to correct component.
Assignee: bryner → bsmedberg
Component: build-config → Startup and Profile System
QA Contact: bsmedberg
Blizzard or somebody else good at shell scripting should handle this. The new
xremote checks blizzard added (particular profiles, etc) probably need to get
included in this script, and I don't know what to do if you pass an unrecognized
commandline option (for instance, what does this patch do if you call ./mozilla
-inspector)?
Assignee: bsmedberg → nobody
Assignee: nobody → nobody
Now I am using the latest mozilla startup script with firebird, which opens a
new firbird window in super fast time!

Don't know how it works...

First open firebird, then open a mozilla (using the mozilla start up script)
then a new firebird window opens!

All under linux RH9.
*** Bug 243178 has been marked as a duplicate of this bug. ***
(In reply to comment #36) 
> Blizzard or somebody else good at shell scripting should handle this. 
 
Fwiw, the Debianized versions of Firefox don't have this problem, so someone 
has already solved this (unless it's so particular to Debian to be unusable by 
anyone else, which I doubt). 
(In reply to comment #39)
> (In reply to comment #36) 
> > Blizzard or somebody else good at shell scripting should handle this. 
>  
> Fwiw, the Debianized versions of Firefox don't have this problem, so someone 
> has already solved this (unless it's so particular to Debian to be unusable by 
> anyone else, which I doubt). 

This would depend on the specific deb package.  If you just download firefox and
run it in debian (I use MEPIS which is a debian sid based distro) it does not
work properly.  The patches I've seen so far are ugly; some work, but all the
ones I've seen leave stuff running in the tray & the screen pointer shows the
system is busy for a few seconds each time a new url is launched.  If you've
found a clean one, I'd like to see it!

Lance
I checked in this patch... it does not fix all cases however e.g. if I launch
one instance with ./firefox -P debug and then another, it fails to find the
running instance the second time. It does fix the common case of launching with
./firefox however so it'll do for now. Clearing '+' flag and retargeting. This
patch is in on branch and trunk. If anyone can make a better patch to fix it for
the other cases feel free to re-attach it and nominate for blocking1.0?
Status: NEW → ASSIGNED
Flags: blocking0.9+
Priority: -- → P3
Target Milestone: Firefox0.9 → After Firefox 1.0
OK, resummarizing to reflect the remaining problem - we need a solution so that
the start script can handle URL parameters so that we can place the script in
the various gnome registries as being the "default handler" for things like
http. This is required for implementation of the GNOME shell service.
blocking1.0+. The patch supplied and checked in will do for .9
Assignee: nobody → bugs
Status: ASSIGNED → NEW
Flags: blocking1.0+
Priority: P3 → P2
Summary: Profile manager appears when trying to launch a second window in Linux → Start Script does not handle URL parameters
Target Milestone: After Firefox 1.0 → Firefox1.0beta
(In reply to comment #42)
> OK, resummarizing to reflect the remaining problem - we need a solution so that
> the start script can handle URL parameters so that we can place the script in
> the various gnome registries as being the "default handler" for things like
> http. This is required for implementation of the GNOME shell service.
> blocking1.0+. The patch supplied and checked in will do for .9

Ummm, Not as far as I know.  While I assume Gnome users are affected along with
everyone else; KDE, icewm, window maker & every other environment are afflicted
with this problem as well.  I don't believe we are looking for a "Gnome-only
solution," if that's what you're proposing.

Lance
(In reply to comment #41)

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

I went to mozilla/dist/bin/ and ran ./firefox 
The script exited with no error.
I ran ./firefox http://www.mozilla.org
Firefox ran fine and went to mozilla.org

I backed out the patch (cvs update -j1.3.4.1 -j1.3
mozilla/browser/app/mozilla.in), and rebuilt, and now it when running ./firefox
with or without an address works fine.

SuSE 9.0
Hmm ... if we've broken running ./firefox with no params then we should back
this out ASAP. Also Ben, I know you said you checked this in on the trunk, but I
don't see the relevant checkin...
yeah, just launching the new process from a command line is busted now

we need a fix/backout by the end of today
Flags: blocking0.9+
Can we please use valid bourne shell syntax too?

./firefox: syntax error at line 125: `(' unexpected


I don't know which patch here got checked in, but none of them are really
acceptable.  A better option would be something like the script included with
the RPM:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/yum/SeaMonkey/releases/current/redhat/9/i386/mozilla-1.6-0.9.0.i386.rpm

bug 122698 was my attempt to integrate that functionality into the seamonkey
startup, but it's side effects were not deemed worse than not doing anything
(the side-effects were part of XRemote and have been partially fixed).  The
patch there is worlds ahead of what is being done here.
(In reply to comment #41)
> I checked in this patch... it does not fix all cases however e.g. if I launch

I wonder if this checkin caused the regression in bug 244774. If so, we should
back it out ASAP and find a better patch.
Backed out. It'll have to be as it was for .9. Better changes for 1.0. Someone
that knows shell scripting should probably begin to experiment with this ;-)
Status: NEW → ASSIGNED
Flags: blocking0.9+
Summary: Start Script does not handle URL parameters → Better Start Script for Firefox
The line 

+    $MOZ_CLIENT_PROGRAM 'ping()' 2>/dev/null >/dev/null

Should probably be

+    $MOZ_CLIENT_PROGRAM -a firefox 'ping()' 2>/dev/null >/dev/null

to only match applications named "firefox"...  Then there shouldn't be this
thunderbird issue.
that seems to work, going to test this thoroughly though
Does that resolve comment 47?
Ugh, it looks like xremote is completely broken on branch. With a Firefox window
open I get this:

[aebrahim@palevsky-223-084 aebrahim]$ firefox -remote
"openurl(http://www.mozilla.org,new-tab)"
Error: No running window found

Works fine on trunk.
*** Bug 234359 has been marked as a duplicate of this bug. ***
checked in the modified version of the script with bz's suggestion on branch and
trunk, this appears to be working well in all of my testing, please test this
ASAP and feed back issues here.  Thanks!

note that this still has the issue ben described with finding the running
instance if a profile was specified.  There is syntax for checking profiles, but
not documented yet.


I think this line:

MOZ_CLIENT_PROGRAM=$curdir/mozilla-xremote-client

should actually be:

MOZ_CLIENT_PROGRAM=$dist_bin/mozilla-xremote-client

The current script doesn't work unless I'm in the Firefox app directory or a
directory with a symlink (it doesn't work anywhere else even though the symlink
is in my path).  With this change, it works from anywhere.
Apparently the latest checkin to mozilla/browser/app/mozilla.in:1.4 breaks the
shell execution on FreeBSD and Solaris 8:

$ dist/bin/firefox 
dist/bin/firefox: 125: Syntax error: "(" unexpected
Attached patch make script functional + cleanup (obsolete) — — Splinter Review 
this includes Tai-hwa's change along with invoking mozilla-xremote-client with
run-mozilla.sh so that it actually works, using '-a firefox' both times so that
it doesn't open the window in Seamonkey.  Also, mozilla-xremote-client can
return 0 to 4 and only 0 means success.
Attachment #149659 - Attachment is obsolete: true
fixes the bourne shell issue, and invoking firefox from a path (comment 57)

this is on trunk and branch as of now, please test ASAP
When the script is invoked with -p or -pure, it sets MOZILLA_BIN to
firefox-bin.pure in line 152.

In
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-06-01-08-trunk/firefox-i686-linux-gtk2+xft.tar.gz
and
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-06-01-04-trunk/firefox-i686-pc-linux-gnu.tar.gz
there's no "firefox-bin.pure" file.

Also, I'd suggest to set it to "${MOZILLA_BIN}.pure", because in line 120,
MOZILLA_BIN is set to firefox-bin. This way, there's just one place where it has
to be differentiated between firefox, seamonkey, sunbird, thunderbird....
In line 73, it still has "set -x" enabled.

The script has "firefox" hardcoded in too many places. IMO, it would be better
to make that dependant on $0. Attached patch does this.

Further, variables should always be enclosed in ", as the content may contain
spaces.
When I start firefox for the 1st time by running the script, a window opens.
Then I start firefox for the 2nd time. When I just call "firefox" (ie. NO
arguments), a new window opens. However, when I give an argument like
"http://mozilla.org/" (ie. I run: "firefox http://mozilla.org/"), the profile
selector window shows up.

Either the ProfileManager should show up ALWAYS (ie. also when "firefox" is
called w/o arguments while already running with) or NEVER (ie also NOT when,
while already running, the firefox script is called with an URL argument).

I'd like to have the 2nd way - ie. ProfileManager should NOT show up. The
attached patch does just that.

It checks, if the first argument starts with a - (dash). If so, it basically
skips the rest of the logic. If 1st arg does NOT start with a -, then it checks
if the arg seems to be a local file. If it is a file, and if the file has not
been specified as an absolute path (ie. something like "../file.htm" instead of
"/tmp/file.htm"), it makes an absolute path out of the argument.
Could the script itself be attached, because it's a pain to apply several
patches.. (for testing ;)
Attached file Firefox starter script (obsolete) — 
My "firefox" starter script with patches 149815 and 149816 applied.
Attachment #149815 - Attachment is obsolete: true
Attachment #149816 - Attachment is obsolete: true
Attachment #149822 - Attachment mime type: application/octet-stream → text/plain
*** Bug 245309 has been marked as a duplicate of this bug. ***
(In reply to comment #65)
> Created an attachment (id=149822)
> Firefox starter script
> 
> My "firefox" starter script with patches 149815 and 149816 applied.

I like this script a lot. It seems to handle all three cases correctly: calling
the script with no arguments, with a special script argument, and with a URL.

I'm going to use this script from now on until it gets checked in.
testing with this, I get error 509 invoking the script with a URL in a couple
cases, one being from GAIM using the default browser setting (after setting it
up in Preferred Applications).	I get the same error invoking with a URL from a
terminal.

however, I am able to open links in new windows from evolution and thunderbird,
so we're getting there.  Any ideas on what could be messing up the launching?
Attachment #112126 - Attachment is obsolete: true
Attachment #112269 - Attachment is obsolete: true
Attachment #137661 - Attachment is obsolete: true
Attachment #138232 - Attachment is obsolete: true
Attachment #149681 - Attachment is obsolete: true
Attachment #149764 - Attachment is obsolete: true
(In reply to comment #68)

> I get the same error invoking with a URL from a
> terminal.

Couple of questions:
1) You used my script? 
2) Which URL did you pass to the script, so that you got that error that you're
getting? 
3) Which shell is your /bin/sh? For me, it's base 2.05b from the Mandrake
package bash-2.05b-16mdk.

I'm using GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu) (base
from Fedora Core 2)
oh, and I was using http://www.mozilla.org, and www.mozilla.org
Comment on attachment 149961 [details] [diff] [review]
diff of the patch above

>-  MOZ_USER_DIR="%MOZ_USER_DIR%"
>+  MOZ_USER_DIR=".firefox"

this is generated.  don't change it.  it's not "hard-coded".

>-moz_libdir=%MOZAPPDIR%
>-MRE_HOME=%MREDIR%
>+moz_libdir=/usr/local/lib/firefox-0.8.0+
>+MRE_HOME=/usr/local/lib/mre/mre-0.8.0+

same.

>-MOZILLA_BIN="%MOZILLA-BIN%"
>+MOZILLA_BIN="${progbase}-bin"

more of the same.

> # The following is to check for a currently running instance.
> # This is taken almost verbatim from the Mozilla RPM package's launch script.
>-MOZ_CLIENT_PROGRAM=$dist_bin/mozilla-xremote-client
>+MOZ_CLIENT_PROGRAM="$dist_bin/mozilla-xremote-client"
> check_running() {
>-    $MOZ_CLIENT_PROGRAM -a firefox 'ping()' 2>/dev/null >/dev/null
>+    "$MOZ_CLIENT_PROGRAM" -a "${progbase}" 'ping()' 2>/dev/null >/dev/null

this whole thing is still non-functional (although differently than before)
because it's not invoked with run-mozilla.sh

see my previous patch.

>+			exec "$MOZ_CLIENT_PROGRAM" -a "${progbase}" "${_remote_cmd}"

still needs run-mozilla.sh

>+			unset _remote_cmd _open_type
>+		fi
>+	else
>+		# No command line args. Open new window/tab
>+		echo exec "$MOZ_CLIENT_PROGRAM" -a "${progbase}" "xfeDoCommand(openBrowser)"

why echo?  The current script echos only when invoking the debugger.

>+		exec "$MOZ_CLIENT_PROGRAM" -a "${progbase}" "xfeDoCommand(openBrowser)"

this needs run-mozilla.sh too.

>-    -p | -pure)
>-      MOZILLA_BIN="%MOZILLA-BIN%.pure"
>+    -p | --pure | -pure)
>+      MOZILLA_BIN="${MOZILLA_BIN}.pure"

ack.  stop that.
Andrew, the current startup script in CVS works fine without run-mozilla.sh,
you're the only person who's reported that it doesn't.  What type of error are
you getting?  Also, do you get the same using a nightly build?
mozilla-xremote-client exits with code 127 when not invoked with run-mozilla.sh
because it can't find relevant libraries.  I'm probably the only one seeing it
because I'm not doing a static build.  run-mozilla.sh sets LD_LIBRARY_PATH. 
Does the startup script now assume a static build?
(In reply to comment #74)
> mozilla-xremote-client exits with code 127 when not invoked with run-mozilla.sh
> because it can't find relevant libraries.  

I think, I made a mistake. I had some RPMs from my distribution installed, which
put those "relevant" libraries in /usr/lib. Because of that, the script always
worked for me ;)

(In reply to comment #72)
> this is generated.  don't change it.  it's not "hard-coded".

Yes, you're right.

I'm attaching a new *firefox* start script and also a mozilla.in script;
further, I'll attach diff's to "mozilla.in,v 1.6" which is currently in CVS.

I tested my script in the following way:

(1) Start a new firefox instance: ~/firefox/firefox
(2) While the instance is still running, call it again with no arguments. A new
window pops up: ~/firefox/firefox
(3) While instance runs, call it with an argument to load an URL. A new window
should pop up, loading that URL: ~/firefox/firefox http://example.com/
(4) While instance runs, call it with a "-remote" argument to load an URL in a
new winodw: ~/firefox/firefox -remote 'openURL(http://example.org/ , new-window)'
(5) While instance runs, call it to show a new tab: ~/firefox/firefox -remote
'openURL(http://example.net/ , new-tab)'
(6) Quit the running firefox instance
(7) Now, with NO running instance, call it to show a new tab: ~/firefox/firefox
-remote 'openURL(http://example.net/ , new-tab)'

I'm *NOT* sure about the expected behaviour of step (7). Currently, *NO* window
shows up, and I only get an error message: "Error: No running window found."

Other than that, the above steps worked fine - ie. I always got the expected
behaviour.

All of these steps worked fine with a build showing this in about:buildconfig:

--disable-ldap --disable-mailnews
--enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,typeaheadfind,webservices,inspector,gnomevfs,negotiateauth
--enable-crypto --disable-composer --disable-profilesharing --disable-freetype2
--disable-debug --enable-shared --disable-static
'--enable-optimize=-march=athlon-xp -msse -funit-at-a-time -funroll-loops
-fpeel-loops -funswitch-loops -Os -pipe -fomit-frame-pointer -freorder-blocks
-fno-reorder-functions -gstabs+' --disable-debug-modules --disable-gtk
--disable-pedantic --disable-tests --disable-toolkit-gtk --disable-toolkit-qt
--disable-toolkit-xlib --enable-default-toolkit=gtk2 --enable-mathml
--enable-plaintext-editor-only --enable-strip --enable-toolkit-gtk2 --enable-xft
--with-default-mozilla-five-home=/usr/local/firefox --with-user-appdir=.firefox

As you can see, that's a build with --enable-shared --disable-static.
Attached patch Start script w/ run-mozilla.sh (obsolete) — — Splinter Review 
As described in comment #75
Attachment #149822 - Attachment is obsolete: true
See comment #75
This is the complete start script made from patch in comment #76.
As described in comment #75

This is the start script for firefox. Comment #76 and #77 added the mozilla.in
"template".
As described in comment #75

This is the start script for firefox. Comment #76 and #77 added the mozilla.in
"template".

This is the complete start script made from patch in comment #78.
(In reply to comment #74)
> mozilla-xremote-client exits with code 127 when not invoked with run-mozilla.sh
> because it can't find relevant libraries.  I'm probably the only one seeing it
> because I'm not doing a static build.  run-mozilla.sh sets LD_LIBRARY_PATH. 
> Does the startup script now assume a static build?

apparently I was wrong.  I grabbed a 0.9 nightly (2004-06-08) and had the same
problem.  mozilla-xremote-client exited with code 127
after install firefox fails to start
 2891  gunzip -dc firefox-0.9rc-i686-linux-gtk2+xft-installer.tar.gz |tar -xvf -
 2892  cd firefox-installer/

 2894  ./firefox-installer
worked
 2895  firefox
no go
 2896  ./firefox
no go
 2898  source firefox
konsole/ kde just whispered away on that one

 2901  firefox cnn.com
nothing
running fedora 1/ I have moz 1.7 installed
Mozilla 1.7
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514
Since this new script, I've got a bug :
When I've got firefox launched by a user, and I try to launch it with another
user, a new firefox window is created, but it belongs to the first user...

Steps to reproduce :
1. Login as a normal user
2. Launch Fx -> you've got your usual profil...
3. Open a console and change user (with su : for exemple, got root)
4. Launch Fx in this console
5. You've got a new Fx window, but using the same profile than before (and not
the root profile for exemple)
6. Check with ps to see that the second window is owned by the first user...
(In reply to comment #80)
> (In reply to comment #74)
> > mozilla-xremote-client exits with code 127 when not invoked with run-mozilla.sh
> > because it can't find relevant libraries.  I'm probably the only one seeing it
> > because I'm not doing a static build.  run-mozilla.sh sets LD_LIBRARY_PATH. 
> > Does the startup script now assume a static build?
> 
> apparently I was wrong.  I grabbed a 0.9 nightly (2004-06-08) and had the same
> problem.  mozilla-xremote-client exited with code 127


I'll second this. mozilla-xremote-client doesn't work on Solaris unless
LD_LIBRARY_PATH includes the mozilla directory:

% ./mozilla-xremote-client
ld.so.1: ./mozilla-xremote-client: fatal: relocation error: file
./mozilla-xremote-client: symbol PR_NewLogModule: referenced symbol not found
zsh: killed     ./mozilla-xremote-client
% LD_LIBRARY_PATH=`pwd` ./mozilla-xremote-client
Usage: mozilla-xremote-client [-a firefox|thunderbird|mozilla|any]
                              [-u <username>]
                              [-p <profile>] COMMAND
%

This results in a spurious "Killed" when launching firefox on Solaris:

% ./firefox
Killed
*** loading the extensions datasource
%

and presumably failure to detect running instances...


(In reply to comment #83)

> I'll second this. mozilla-xremote-client doesn't work on Solaris unless
> LD_LIBRARY_PATH includes the mozilla directory:

Do you still have this problem, even with the new start script
http://bugzilla.mozilla.org/attachment.cgi?id=150144&action=view attachment
(id=150144) , which uses run-mozilla.sh?
(In reply to comment #82)
> Since this new script, I've got a bug :

Ie. with the script ftom attachment (id=150144)?

> Steps to reproduce :

First: I cannot reproduce this.

> 1. Login as a normal user
> 2. Launch Fx -> you've got your usual profil...
> 3. Open a console and change user (with su : for exemple, got root)

Uhm, what did you type? su or "su -" (no ")? The correct way would be to do "su
-", to ensure that the profile is reset to that of the user changing to (in your
case root - which is a nono *G*).

> 4. Launch Fx in this console
> 5. You've got a new Fx window, but using the same profile than before (and not
> the root profile for exemple)
> 6. Check with ps to see that the second window is owned by the first user...

As I said, cannot reproduce this. Even with the IMO wrong "su" (no dash), the
second firefox is running as the su'd user and with the su'd users profile. Not
as the original user.
I just noticed one cause of those "Error: Failed to send command: 509 internal
error" errors. When the URL for openURL() does not end with a /, I'm getting
this 509.

Please see bug #247664 for this.

As explained there, I do NOT think, that the proper place to fix "malformed"
URLs (like http://example.net - note the missing trailing slash) is a wrapper
script. The proper place IMO is to have openURL() also accept such URLs.
(In reply to comment #84)
> (In reply to comment #83)
> 
> > I'll second this. mozilla-xremote-client doesn't work on Solaris unless
> > LD_LIBRARY_PATH includes the mozilla directory:
> 
> Do you still have this problem, even with the new start script
> http://bugzilla.mozilla.org/attachment.cgi?id=150144&action=view attachment
> (id=150144) , which uses run-mozilla.sh?

Well, err, I'm not sure. With the attachment, I get:

% ./firefox
./firefox: [[: not found
./firefox: [[: not found
./firefox: -n: not found

Can we *please* stop using bash syntax in a /bin/sh script? See comment 47.



> Can we *please* stop using bash syntax in a /bin/sh script? See comment 47.

the script works with both bash and ash (lean-mean sh).  If it's not working for
you, you'll need to figure out what's wrong or patiently wait for someone else
to figure it out.  Complaining won't help.
(In reply to comment #88)
> > Can we *please* stop using bash syntax in a /bin/sh script? See comment 47.
> 
> the script works with both bash and ash (lean-mean sh).  If it's not working for
> you, you'll need to figure out what's wrong or patiently wait for someone else
> to figure it out.  Complaining won't help.

I think you missed the point. Anything run in /bin/sh needs to use bourne
shell syntax. /bin/sh happens to be bash on Linux, but that doesn't make it
acceptible to use bash syntax and features in a script like this - you
preclude it from running on any other platform where /bin/sh is not bash
(or similarly augmented).

I'm trying to clean it up right now, but there's some pattern matching stuff
being liberally used, for which there is no nice bourne shell equivalent.

If bash is the way it's going to be, the first line of the script needs to
be changed to "#!/bin/bash".



I believe this patch keeps the functionality while removing bash-specific
syntax and pattern-matching features.
Attached file mozilla.in w/o bash req. (obsolete) — 
As requested in comment #90 - script which does not require bash.

This is mozilla.in
Attachment #150140 - Attachment is obsolete: true
Attachment #150142 - Attachment is obsolete: true
Attached file Firefox starter script w/o bash req. (obsolete) — 
As requested in comment #90 - script which does not require bash.

This is the actual firefox startet script.
Attachment #150143 - Attachment is obsolete: true
Attachment #150144 - Attachment is obsolete: true
Comment on attachment 151213 [details]
mozilla.in w/o bash req.

Obsoleting in favor of:
attachment (id=151211)
attachment (id=151212)
Attachment #151213 - Attachment is obsolete: true
Comment on attachment 151214 [details]
Firefox starter script w/o bash req.

Obsoleting in favor of:
attachment (id=151211)
attachment (id=151212)
Attachment #151214 - Attachment is obsolete: true
(In reply to comment #85)
> (In reply to comment #82)
> > Since this new script, I've got a bug :
> 
> Ie. with the script ftom attachment (id=150144)?
Oh, I'm so sorry : I was talking of the script in Fx0.9, or in the 2004-06-17
trunk nightly. I suppose that it isn't the latest (I said "new" because there
wasn"t such script with Fx 0.8 for example)

> Uhm, what did you type? su or "su -" (no ")? The correct way would be to do "su
> -", to ensure that the profile is reset to that of the user changing to (in your
> case root - which is a nono *G*).
The dash is only needed when we want to use some environment vars of the new user.
I don't see why this could have importance here, because even without it,
$USER,$HOME, and  $PATH are set to the right values ...

But if you say that it has been corrected, I believe you, and I'm ready to test
it on a new nightly ;¬)
*** Bug 247143 has been marked as a duplicate of this bug. ***
Hello, I've been enjoying the start script from comment #79, attachment 150144 [details],
for a few weeks now. It worked very well. The only time I saw the profile
manager was when I was downloading something large, closed Firefox and then
tried to open it again with the icon on my desktop. It worked perfectly in all
other situations. 
But now, I've just rebuilt Firefox, there are new icons on the taskbar, the
profile is now in ~/.mozilla/firefox and the profile manager is back with a
vengence. Something has changed, it's broken the script in some way.
Depends on: 246168
*** Bug 249072 has been marked as a duplicate of this bug. ***
Assignee: bugs → bryner
Status: ASSIGNED → NEW
*** Bug 249524 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0RC1+
This is a bug and not a preferences problem, since it makes it virtually
impossible to use firefox as a default browser: whenever I click on a link from
another application the profile manager keeps coming up. I can in theory
copy/paste the link to the browser, even if it's really annoying, but this is
not always the case; for example, in gnome crash reports, some online helps etc
the browser opens automatically without a link being visible to user.
The patches described here didn't help because -remote always reports that it
can't find a running window.
I'm running Mandrake 9.2 and Firefox 0.9.1

Any chance of http://bugzilla.mozilla.org/attachment.cgi?id=151212&action=view
getting checked in anytime soon? The problems Andrew reported in comment #98
didn't have anything to do with this script (I worked with him "off-bugzilla" to
confirm this). So, it seems to me that Iains optimization of my script is the
best choice right now.
But the script doesn't work in current trunk builds. It works for the 0.9 branch
but not on the trunk.
Well, yes, trunk is broken and the script doesn't work there. However, that's 
so because of the following: 
 
./run-mozilla.sh ./mozilla-xremote-client -a firefox 'ping()' 
./mozilla-xremote-client: Error: Failed to find a running server. 
 
So, mozilla-xremote-client is having problems finding a running server. Because 
of this, the script is failing. But, the script is failing because 
mozilla-xremote-client is failing - that's the cause. 
That's true, the fault isn't with your script. Is there a separate bug for the
mozilla-xremote-client problem?
Hm, Bug #247217 also deals with mozilla-xremote-client not working. While this
bug is filed agains Tb, I don't think it is a Tb bug.

On a side note, 247664 should also get fixed for the script to work properly.
Depends on: 247664
The trunk xremote problem should be fixed now; I landed the patch for bug 244060.
Indeed, it is fixed! The wicked profile manager has been defeated once more!
Thankyou!
This is attachment 151212 [details] with the results of preprocessing reverted
(moz_libdir, MRE_HOME and the like).
Comment on attachment 152441 [details] [diff] [review]
patch against cvs

r=bryner
Attachment #152441 - Flags: review+
Blocks: 246609
Blocks: 246977
Blocks: 250224
(In reply to comment #108)
> Indeed, it is fixed! The wicked profile manager has been defeated once more!
> Thankyou!

How do I make this fix work for me?  I just grabbed the most recent mozilla
source from CVS and used it to build firefox, but I still get the profile
manager when I try to run a second copy of firefox.

Thanks.

(In reply to comment #111)

> How do I make this fix work for me?  I just grabbed the most recent mozilla
> source from CVS and used it to build firefox, but I still get the profile
> manager when I try to run a second copy of firefox.

You take attachment 151212 [details] and replace the firefox script with the one you just
downloaded. When you then run "firefox http://example.com/" while another Fx
instance is running, the profile manager should NOT come up.

Also, please explain how EXACTLY you ran firefox. Further, did you build branch
or trunk?
Checkedin attachment 152441 [details] [diff] [review] on the trunk and AVIARY_1_0_20040515_BRANCH.  Thanks
for the patch.
Status: NEW → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → FIXED
(In reply to comment #112)
> (In reply to comment #111)
> 
> > How do I make this fix work for me?  I just grabbed the most recent mozilla
> > source from CVS and used it to build firefox, but I still get the profile
> > manager when I try to run a second copy of firefox.
> 
> You take attachment 151212 [details] and replace the firefox script with the one you just
> downloaded. When you then run "firefox http://example.com/" while another Fx
> instance is running, the profile manager should NOT come up.
> 
> Also, please explain how EXACTLY you ran firefox. Further, did you build branch
> or trunk?

Hi.  Thank you very much for your help.  The next message down from yours said
something about checking in a script, so I did a rebuild today, and it's working
now.

I built from the trunk, and I did

  cd dist/bin
  ./firefox www.google.com
  ^z
  bg
  ./firefox www.cnn.com

This didn't work yesterday, but does work now.  So I guess there's nothing
else to be done here, but I just want to say again that I appreciate your
willingness to help.

Greg
*** Bug 250224 has been marked as a duplicate of this bug. ***
Will using a nightly build from either 2004-07-09-09-0.9, 2004-07-09-09-trunk,
or 2004-07-09-10-trunk work to fix this?
*** Bug 246609 has been marked as a duplicate of this bug. ***
(In reply to comment #116)
> Will using a nightly build from either 2004-07-09-09-0.9, 2004-07-09-09-trunk,
> or 2004-07-09-10-trunk work to fix this?

Fix what? Per comment 113, the patch was checked into both the trunk and the
aviary branch on July 8th, so those nightly builds should include it, and
hence should work correctly. Check the firefox script for a version like:

## $Id: mozilla.in,v 1.3.4.6 2004/07/08 07:09:55 bryner%brianryner.com Exp $


Ah... I think I found another bug then.  Starting firefox with -P default always
gives me the profile manager.  Shouldn't it be the same as starting firefox
without arguments?  If I start it with -P SomeOtherProfile, it just starts up
using SomeOtherProfile without prompting me.
Actually I'm having some weird behavior when I use -P, but some of it may be
related to version screw up.  If I remove my ~/.mozilla/firefox directory, I can
at least get the following behavior consistently, which I believe is incorrect:

firefox &
firefox -P default

The second instance brings up the profile manager.  I believe it should not, and
should just be exactly the same as calling it without arguments.  I can get the
same behavior if I do "firefox -P SomeOtherProfile &; firefox -P
SomeOtherProfile &".  The second instance should not bring up the profile
manager, and should instead open up a new window using the given profile.

Should I file this as a separate bug?
(In reply to comment #120)
> Actually I'm having some weird behavior when I use -P, but some of it may be
> related to version screw up.  If I remove my ~/.mozilla/firefox directory, I can
> at least get the following behavior consistently, which I believe is incorrect:
> 
> firefox &
> firefox -P default
> 
> The second instance brings up the profile manager.  I believe it should not, and
> should just be exactly the same as calling it without arguments.  I can get the
> same behavior if I do "firefox -P SomeOtherProfile &; firefox -P
> SomeOtherProfile &".  The second instance should not bring up the profile
> manager, and should instead open up a new window using the given profile.
> 
> Should I file this as a separate bug?

Hmm, this could be a can of worms. Running firefox without specifying a
profile is not exactly the same as specifying the "default" profile. What
would you expect to see if you had an instance already running using
"SomeOtherProfile", and then you ran "firefox -P default"? I think you'd
expect a new instance. 

IMO, the definition of the '-P <profile>' argument should be "Start a
new instance using the profile <profile>", but I'm not sure where such
definitions are absolutely stated.


> Hmm, this could be a can of worms. Running firefox without specifying a
> profile is not exactly the same as specifying the "default" profile. What
> would you expect to see if you had an instance already running using
> "SomeOtherProfile", and then you ran "firefox -P default"? I think you'd
> expect a new instance. 

I'd expect it to do the same thing it currently does when you don't specify a
profile: it tries to find an existing process (using the last opened profile),
and opens a window with that.

If you are using more than one profile, then naturally you will want the ability
to open a new window under an existing process using that profile.

> IMO, the definition of the '-P <profile>' argument should be "Start a
> new instance using the profile <profile>", but I'm not sure where such
> definitions are absolutely stated.

Well, here's the scenario: I have two profiles that I use actively.  The reason
I have two profiles is bug 20573: one profile is only for one window, which I
use for API and bug tracking, which is almost full screen.  The other profile I
use for all my other browsing needs, which includes several browser windows.

When I start new browser windows (either my clicking my Firefox button launcher,
or clicking on a URL link from another program), I expect Firefox to use my
default profile.  So it doesn't actually use my other profile (and thus open up
a big annoying window at almost full screen), I set both my URL handler and
button action to "firefox -P default".  I have a separate button to launch the
other profile exclusively with action "firefox -P OtherProfile".

I'm assuming the whole idea of using multiple profiles is something like my
scenario, but of course I'm biased.  :)  Does it really make more sense to have
-P start up a new process?  I don't understand why firefox with no arguments,
which does NOT start a new process if the default profile (or whatever last
profile was used) is already running, is different than explicitly giving that
same profile with -P.
(In reply to comment #122)
> > Hmm, this could be a can of worms. Running firefox without specifying a
> > profile is not exactly the same as specifying the "default" profile. What
> > would you expect to see if you had an instance already running using
> > "SomeOtherProfile", and then you ran "firefox -P default"? I think you'd
> > expect a new instance. 
> 
> I'd expect it to do the same thing it currently does when you don't specify a
> profile: it tries to find an existing process (using the last opened profile),
> and opens a window with that.

But that'd be wrong, wouldn't it? That window would be using "SomeOtherProfile"
and not "default", as you had requested.


> If you are using more than one profile, then naturally you will want the ability
> to open a new window under an existing process using that profile.

It appears the mozilla-xremote-client doesn't require the profile name
that's passed to it when selecting a window to manipulate - it just uses
the best window it can find, which may be one using a different profile,
if none matches the profile specified.

This could be considered a bug, I suppose .. but it's debatable. If
it was fixed to require the profile specified, the firefox script could
be tweaked to utilise that, and probably satisfy your needs. I think this
really should be a new bug (/RFE), though...



-P has historically meant the same thing as -ProfileManager.  We briefly didn't
have that, we got negative feedback from users, and we restored that.  I don't
see a reason to make -P mean nothing without an arg, since its obviously a
commandline switch with some meaning.

IIRC, there is logic (undocumented at this point) to allow checking for instance
by active profile.  However, this isn't a priority at this point since we're not
going to be actively focusing on multiple profiles (and to an extent will be
de-emphasizing them).

The latter should have its own bug to track further refinements, but for 95% of
users, its probably unnecessary.
(In reply to comment #123)
> But that'd be wrong, wouldn't it? That window would be using "SomeOtherProfile"
> and not "default", as you had requested.

Exactly.  Hence my problem.

> It appears the mozilla-xremote-client doesn't require the profile name
> that's passed to it when selecting a window to manipulate - it just uses
> the best window it can find, which may be one using a different profile,
> if none matches the profile specified.

I just experimented with mozilla-xremote-client, and it looks like it ignores
the profile argument completely.

> This could be considered a bug, I suppose .. but it's debatable. If
> it was fixed to require the profile specified, the firefox script could
> be tweaked to utilise that, and probably satisfy your needs. I think this
> really should be a new bug (/RFE), though...

Just filed bug 251134 to address this issue in particular. 
(In reply to comment #124)
> IIRC, there is logic (undocumented at this point) to allow checking for instance
> by active profile.  However, this isn't a priority at this point since we're not
> going to be actively focusing on multiple profiles (and to an extent will be
> de-emphasizing them).

Is there a way for me to make it work?  Please reply in bug 251134... thanks!
*** Bug 246977 has been marked as a duplicate of this bug. ***
mozilla-xremote-client is only returning 0 for me...

# one term
-(~) firefox
[running]

# another
-(~) firefox -remote 'ping()' ; echo $?
0

I'm usin 8/3 (mozilla.org) builds of the 0.9+ branch. Am I doing something wrong? :S
Comment 128: no, exit status 0 means the ping succeeded.

However, I have a different problem. I made a symlink to the script in
/usr/local/bin (which is in my path). Now, although the real script correctly
opens a new window when Firefox is running, the symlink only opens the profile
manager, unless the current directory is /usr/local/bin.
Ok sorry, I see it now. -remote 'ping()' with nothing running returns 2.

As far as the /usr/local/bin bit, that's what it is. If I chdir, then run
firefox it's ok. For me, run_moz is set to '../run-mozilla.sh'; if set to
/usr/local/firefox/run-mozilla.sh, all is well.

How about this?

--- firefox.orig        2004-08-03 10:14:08.000000000 -0500
+++ firefox     2004-08-03 16:28:04.000000000 -0500
@@ -99,6 +99,7 @@
     if [ -x "$run_moz" ]; then
       cd "$curdir"
       dist_bin=`pwd`
+      run_moz="$dist_bin/run-mozilla.sh"
       found=1
       break
     fi
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
  

        Attachment #156074 -
        Flags: review?(bsmedberg)

    
    

    
  
Comment on attachment 156074 [details] [diff] [review]
one-liner for my issue

Since bryner reviewed the first patch and knows what's going on, maybe you
should have asked him for review instead of me ;)

        Attachment #156074 -
        Flags: review?(bsmedberg) → review?(bryner)

    
  
Whiteboard: [have patch]

    
  

        Attachment #156074 -
        Flags: review?(bryner) → review+

    
  

        Attachment #156074 -
        Flags: approval-aviary?

    
    

    
  
Comment on attachment 156074 [details] [diff] [review]
one-liner for my issue

a=chofmann

        Attachment #156074 -
        Flags: approval-aviary? → approval-aviary+

    
    

    
  
Comment on attachment 152441 [details] [diff] [review]
patch against cvs

a=chofmann

        Attachment #152441 -
        Flags: approval-aviary+

    
    

    
  
checked in
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Blocks: 240696

    
    

    
  
Pardon me, but why does the Fx 0.9.3 release not have this script? Will the
script at least be present in 1.0, once it's out?

    
    

    
  
Firefox 0.9.x is based off 0.9 code, plus a few crash/security fixes.

Its in nightly builds, and works great.  It should be in 1.0PR, which is really
close.

    
    

    
  
*** Bug 256715 has been marked as a duplicate of this bug. ***

    
    

    
  
This has been re-broken on Firefox 1.0rc1.  Anyone else experiencing this?  It
was working great on 0.10.1.

    
    

    
  
Yeah, just exits now. I guess openURL() doesn't like the missing new-window/tab bit?

firefox:179: _remote_cmd="openURL(${_optLast}, new-window)"

    
    

    
  
(In reply to comment #140)
> Yeah, just exits now. I guess openURL() doesn't like the missing
new-window/tab bit?
> 
> firefox:179: _remote_cmd="openURL(${_optLast}, new-window)"

Hm, no? I checked out AVIARY at 20041104 0550 UTC and am able to startup firefox
just fine.

    
    

    
  
Seems to work fine for me too, with a recent (2-day old) aviary build. Can anyone
provide specific steps to reproduce a problem?

    
    

    
  
I've tried a few scenarios, but it's intermittent.  I'll try again today.  I
just know that it had stopped happening completely, and once I upgraded to
1.0rc1, I saw it again.

    
    

    
  
I was expecting a new window and probably used an url which I was already at, so
it just ended up reloading the page and I didn't notice anything... After
retesting (a few times) with 1.0rc1/2, everything seems ok. My bad, sorry :P

    
    

    
  
Sorry to bring this up after so long ...

I've just read through this thread, and it appears that firefox behaves in the
proper manner according to all this discussion.

However, I have a related problem: When I ssh to a different machine and run
firefox, I want firefox to run on that machine, with all the settings I use
there. Unfortunately, since the detection of another instance is done through
the X server, it detects the one on my local machine and uses that instead. (I
ssh to work, and need to access internal web sites)

I believe this is what's being discussed, but not resolved, in this Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229547

Any thoughts on whether it's fixable?

I'm working around it with firefox --noxshm, which I guess stops it talking
through the X server.

    
    

    
  
That's a different bug, please search for it (the basic answer is to export
MOZ_NO_REMOTE=1 if you don't want that behavior, which is by design).

    
    

    
  
Maybe Bug 295945

    
  
Status: RESOLVED → VERIFIED
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: