177996 - Better Start Script for Firefox

Status: VERIFIED FIXED

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

Description

[Scot Hale]

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

Comment 1

[David P James]

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

Comment 2

[Scot Hale]

    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

Comment 3

[David P James]

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?

Comment 4

[André Dahlqvist]

See bug 76431. WONTFIX.

Comment 5

[Scot Hale]

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?

Comment 6

[David P James]

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.

Comment 7

[Scot Hale]

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

Comment 8

[alanjstr]

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

Comment 9

[GoRN ToTheRescue]

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 "$@";

Comment 10

[alanjstr]

Can you generalize that so that the path to Phoenix is not hardcoded?  Perhaps
something to patch the launching script itself.

Comment 11

[David P James]

Reopenning (David eats his own words)

Comment 12

[David P James]

Attachment: launch script patch to open new window rather than profile v0.1

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.

Comment 13

[David P James]

--> 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"

Comment 14

[David P James]

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.

Comment 15

[Jan Villat]

Attachment: launch script patch to open new window rather than profile v0.1b

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.

Comment 16

[David P James]

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

Comment 17

[Andrew Schultz]

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"

Comment 18

[Jan Villat]

Attachment: launch script patch to open new window rather than profile v0.1b

Fixing patch format, sorry guys.

Comment 19

[noririty]

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

Comment 20

[Brian Ryner (not reading)]

I'm planning some upcoming X-Remote work that may affect the way this should be
implemented.  -> 0.7.

Comment 21

[dharter]

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.

Comment 22

[Jacob Keller]

Hm, did you know that you can build it single profile...

Comment 23

[Brian Ryner (not reading)]

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.

Comment 24

[Ton]

Attachment: Script to use remotecommand when Firebird is started a second time

If Firebird is not running it just starts Firebird. If Firebird is running it
opens a new window.

Comment 25

[Joshua Go]

Attachment: Patch to current launch script

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.

Comment 26

[Andrew Benton]

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

Comment 27

[Joshua Go]

My mistake; there is apparently much more involved here than I thought.

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 29

[Jesse Ruderman]

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

Comment 30

[Michael Favia]

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

Comment 31

[Asa Dotzler [:asa]]

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

Comment 32

[Ray Trent]

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?

Comment 33

[Matthias Versen [:Matti]]

This is a linux bug and not Mozilla.
File it as Firebird bug

Comment 34

[Mike Connor [:mconnor]]

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

Comment 35

[Ali Ebrahim]

Moving over to correct component.

Comment 36

[Benjamin Smedberg]

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)?

Comment 37

[Dan Bolser]

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.

Comment 38

[Ali Ebrahim]

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

Comment 39

[David P James]

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

Comment 40

[Lance Haverkamp]

(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

Comment 41

[Ben Goodger (use ben at mozilla dot org for email)]

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?

Comment 42

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 43

[Lance Haverkamp]

(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

Comment 44

[Adam]

(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

Comment 45

[Ali Ebrahim]

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

Comment 46

[Mike Connor [:mconnor]]

yeah, just launching the new process from a command line is busted now

we need a fix/backout by the end of today

Comment 47

[Iain MacDonnell]

Can we please use valid bourne shell syntax too?

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

Comment 48

[Andrew Schultz]

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.

Comment 49

[Ali Ebrahim]

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

Comment 50

[Ben Goodger (use ben at mozilla dot org for email)]

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 ;-) 

Comment 51

[Boris Zbarsky [:bzbarsky]]

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.

Comment 52

[Mike Connor [:mconnor]]

that seems to work, going to test this thoroughly though

Comment 53

[alanjstr]

Does that resolve comment 47?

Comment 54

[Ali Ebrahim]

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.

Comment 55

[Ali Ebrahim]

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

Comment 56

[Mike Connor [:mconnor]]

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.

Comment 57

[donpete+bugzilla]

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.

Comment 58

[Tai-hwa Liang]

Attachment: Make the function prototype more compatiable with /bin/sh

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

Comment 59

[Andrew Schultz]

Attachment: make script functional + cleanup

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.

Comment 60

[Mike Connor [:mconnor]]

Attachment: fix bourne shell syntax and symlink issues

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

Comment 61

[Alexander Skwar]

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

Comment 62

[Alexander Skwar]

Attachment: Add quotes when $VARIABLES are used; use $0 instead of hardcoded "firefox"; comment "set -x"

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.

Comment 63

[Alexander Skwar]

Attachment: Don't show ProfileManager when called with URL-like argument

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.

Comment 64

[Nickolay_Ponomarev]

Could the script itself be attached, because it's a pain to apply several
patches.. (for testing ;)

Comment 65

[Alexander Skwar]

Attachment: Firefox starter script

My "firefox" starter script with patches 149815 and 149816 applied.

Comment 66

[Mike Connor [:mconnor]]

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

Comment 67

[Bradley Chapman (not reading bugmail, still gone but not forever)]

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

Comment 68

[Mike Connor [:mconnor]]

Attachment: diff of the patch above

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?

Comment 69

[Alexander Skwar]

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

Comment 70

[Mike Connor [:mconnor]]

I'm using GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu) (base
from Fedora Core 2)

Comment 71

[Mike Connor [:mconnor]]

oh, and I was using http://www.mozilla.org, and www.mozilla.org

Comment 72

[Andrew Schultz]

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.

Comment 73

[Mike Connor [:mconnor]]

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?

Comment 74

[Andrew Schultz]

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?

Comment 75

[Alexander Skwar]

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

Comment 76

[Alexander Skwar]

Attachment: Start script w/ run-mozilla.sh

As described in comment #75

Comment 77

[Alexander Skwar]

Attachment: Start script w/ run-mozilla.sh - complete

See comment #75
This is the complete start script made from patch in comment #76.

Comment 78

[Alexander Skwar]

Attachment: Start script for FIREFOX w/ run-mozilla.sh

As described in comment #75

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

Comment 79

[Alexander Skwar]

Attachment: Start script for FIREFOX w/ run-mozilla.sh - complete

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.

Comment 80

[Andrew Schultz]

(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

Comment 81

[Dennis Daniels]

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

Comment 82

[Xanthor Sccas]

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

Comment 83

[Iain MacDonnell]

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

Comment 84

[Alexander Skwar]

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

Comment 85

[Alexander Skwar]

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

Comment 86

[Alexander Skwar]

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.

Comment 87

[Iain MacDonnell]

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

Comment 88

[Andrew Schultz]

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

Comment 89

[Iain MacDonnell]

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

Comment 90

[Iain MacDonnell]

Attachment: Patch for previously proposed script to remove bash-specifics

I believe this patch keeps the functionality while removing bash-specific
syntax and pattern-matching features.

Comment 91

[Iain MacDonnell]

Attachment: Complete bash-free script

Comment 92

[Alexander Skwar]

Attachment: mozilla.in w/o bash req.

As requested in comment #90 - script which does not require bash.

This is mozilla.in

Comment 93

[Alexander Skwar]

Attachment: Firefox starter script w/o bash req.

As requested in comment #90 - script which does not require bash.

This is the actual firefox startet script.

Comment 94

[Alexander Skwar]

Comment on attachment 151213 [details]
mozilla.in w/o bash req.

Obsoleting in favor of:
attachment (id=151211)
attachment (id=151212)

Comment 95

[Alexander Skwar]

Comment on attachment 151214 [details]
Firefox starter script w/o bash req.

Obsoleting in favor of:
attachment (id=151211)
attachment (id=151212)

Comment 96

[Xanthor Sccas]

(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 ;¬)

Comment 97

[Ali Ebrahim]

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

Comment 98

[Andrew Benton]

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.

Comment 99

[Robert Parenton]

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

Comment 100

[Robert Parenton]

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

Comment 101

[adepali]

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

Comment 102

[Alexander Skwar]

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.

Comment 103

[Andrew Benton]

But the script doesn't work in current trunk builds. It works for the 0.9 branch
but not on the trunk.

Comment 104

[Alexander Skwar]

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. 

Comment 105

[Andrew Benton]

That's true, the fault isn't with your script. Is there a separate bug for the
mozilla-xremote-client problem?

Comment 106

[Alexander Skwar]

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.

Comment 107

[Brian Ryner (not reading)]

The trunk xremote problem should be fixed now; I landed the patch for bug 244060.

Comment 108

[Andrew Benton]

Indeed, it is fixed! The wicked profile manager has been defeated once more!
Thankyou!

Comment 109

[Brian Ryner (not reading)]

Attachment: patch against cvs

This is attachment 151212 [details] with the results of preprocessing reverted
(moz_libdir, MRE_HOME and the like).

Comment 110

[Brian Ryner (not reading)]

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

r=bryner

Comment 111

[Greg Schussman]

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

Comment 112

[Alexander Skwar]

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

Comment 113

[Brian Ryner (not reading)]

Checkedin attachment 152441 [details] [diff] [review] on the trunk and AVIARY_1_0_20040515_BRANCH.  Thanks
for the patch.

Comment 114

[Greg Schussman]

(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

Comment 115

[Raul Acevedo]

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

Comment 116

[Raul Acevedo]

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?

Comment 117

[Robert Parenton]

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

Comment 118

[Iain MacDonnell]

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

Comment 119

[Raul Acevedo]

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.

Comment 120

[Raul Acevedo]

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?

Comment 121

[Iain MacDonnell]

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

Comment 122

[Raul Acevedo]

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

Comment 123

[Iain MacDonnell]

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

Comment 124

[Mike Connor [:mconnor]]

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

Comment 125

[Raul Acevedo]

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

Comment 126

[Raul Acevedo]

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

Comment 127

[(not currently active) Ted Mielczarek]

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

Comment 128

[logan]

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 129

[Anders Kaseorg]

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.

Comment 130

[logan]

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

Comment 131

[logan]

Attachment: one-liner for my issue

Comment 132

[Benjamin Smedberg]

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 ;)

Comment 133

[chris hofmann]

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

a=chofmann

Comment 134

[chris hofmann]

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

a=chofmann

Comment 135

[Brian Ryner (not reading)]

checked in

Comment 136

[Alexander Skwar]

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?

Comment 137

[Mike Connor [:mconnor]]

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.

Comment 138

[:Gavin Sharp [email: [e-mail]]]

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

Comment 139

[Raul Acevedo]

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

Comment 140

[logan]

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

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

Comment 141

[Alexander Skwar]

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

Comment 142

[Iain MacDonnell]

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

Comment 143

[Raul Acevedo]

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.

Comment 144

[logan]

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

Comment 145

[Richard Hector]

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.

Comment 146

[Benjamin Smedberg]

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

Comment 147

[Xanthor Sccas]

Maybe Bug 295945