122698 - Detect currently running instance of Mozilla when app is launched a second time

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, enhancement)

Description

[Zack Weinberg (:zwol)]

When Mozilla is launched, it should check whether another instance of itself
is already running, and if so, cause the existing instance to open another
window.

This behavior of course needs to be per-user, per-profile, and probably
per-X11-display (I might want to have copies running on multiple displays
out of the same profile).

See also bug 76431.

Comment 1

[Boris Zbarsky [:bzbarsky]]

confirming.  This is pp.

ccing blizzard, since the RPM builds do something like this.

Comment 2

[Christopher Blizzard (:blizzard)]

The all singing all dancing super I know what you meant, not what you said of
communications protocols, eh?  X-remote already does per-user, per-display. 
Per-profile it does not.

Comment 3

[Zack Weinberg (:zwol)]

It doesn't need to be _that_ much cleverer than we have now.  If the
user has multiple profiles, do whatever we do now to figure out which
one the user wants.  Then query all the existing Mozilla processes for
this user on the same display, and if one is running the same profile,
ask it to create a new window.

All that the -remote protocol needs added to it is a way to have it
report what profile it's running, I think.

I'm marking this bug dependent on bug 76431, since we need that to
reliably detect that a profile is in use already.

Comment 4

[Peter Trudelle]

->law/future

Comment 5

[Matthias Versen [:Matti]]

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

Comment 6

[Matthias Versen [:Matti]]

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

Comment 7

[Matthias Versen [:Matti]]

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

Comment 8

[Matthias Versen [:Matti]]

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

Comment 9

[Matthias Versen [:Matti]]

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

Comment 10

[Matthias Versen [:Matti]]

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

Comment 11

[Matthias Versen [:Matti]]

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

Comment 12

[Andrew Schultz]

If this bug is going to be fixed by integrating xremote into the startup
scripts, shouldn't this be Build Config (a Unix-only bug in XP Apps seems a bit
contradictory...)?

Also, xremote still does not distinguish between multiple profiles (such a bug
has not even been filed) -- is that a necessary part of any fix for this bug?

have patch, will post.

Comment 13

[Andrew Schultz]

Attachment: patch to run-mozilla.sh

Comment 14

[Brian 'netdragon' Bober]

I start Mozilla by changing to the bin dir and typing ./mozilla on Linux. Will
this patch also account for that?

Comment 15

[Andrew Schultz]

If you do that while Mozilla is already running, it will open a new browser
window with about:blank.

In fact that's the only way it would work... executing from other directories
doesn't work.  new patch coming up.

Comment 16

[Andrew Schultz]

Attachment: patch v2

patch works from other directories too.

I don't see how the MOZ_DEFAULT_NAME, MOZ_APP_RUNNER_NAME or MOZ_VIEWER_NAME
could have worked properly before.  Perhaps the mozilla script used to change
directories to the Mozilla dir.

Comment 17

[timeless]

fwiw blizzard's magic is in
http://lxr.mozilla.org/mozilla/source/build/package/rpm/SOURCES/mozilla.sh

Comment 18

[Andrew Schultz]

yep.  I guess I should mention that the patch here is basically integrating
Blizzard's Xremote-magic from mozilla.sh (RPM's /usr/bin/mozilla) into
run-mozilla.sh.

==> Build Config

Comment 19

[Bartosz Wucke]

For maximum happiness we should be able to launch different things than browser
that way, so one could freely hook up "mozilla -mail" to biff and open the mail
window when new mail arrive, not trying to remember if the browser is running
already. (would require something new in -remote then, wouldn't it? Or can it be
solved with some chrome:// URL?)

Comment 20

[Andrew Schultz]

"mozilla -mail" is hooked up to mailnews...

if you want to see what this patch does, just apply it to run-mozilla.sh in your
mozilla directory.  building mozilla is not required.

Comment 21

[Andrew Hagen]

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

Comment 22

[Matthias Versen [:Matti]]

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

Comment 23

[R.K.Aa.]

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

Comment 24

[K'Trina Medina]

Adding comments from Michael Hipp . . . . 

I can, with no problems whatsoever, run multiple instances of Opera, Konqueror,
Internet Explorer, Netscape, and even Mozilla (before 1.0rc3) with no worries
about "profile corruption". But all of a sudden, I can't. 

I just know when I click on a link in Kmail that Mozilla refuses to bring it up
simply because another window is open. 

This is a SHOWSTOPPER. This makes Mozilla largely useless as a browser.

So tell me, please, is someone going to fix this particular BugFeature(tm) or not? 

Comment 25

[hacker formerly known as [e-mail]]

I had a nickel for everytime someone claimed that their pet peeve was a
showstopper...

There have been several bugs reported about the "attaching" process used by the
startup script and since we don't use that feature yet, they must've been
talking about the rpm scripts which is where that patch comes from.  If there
are problems with what the rpm version of the script is doing, then we don't
want to blindly copy those into the default script.   These problems should be
addressed first:

bug 149126
bug 112080
bug 151863

Comment 26

[Michael Hipp]

Pardon you. I believe most people would consider it a mandatory feature of a
browser that you be able to click on a link and have the browser come up.

I don't fully understand the ins & outs of the rpm script issue, but I applied
the patch to my run-mozilla.sh and it now works.

AT LEAST that represents someone's attempt to actually fix the problem instead
of telling us how grateful we should all be for this feature that the browser
doesn't come up when you click on a link.

Comment 27

[Andrew Schultz]

you should be grateful to cls that Mozilla works at all!

I filed bug 151909 to have X-remote distinguish between profiles.  This would
help out here and also 151863.

at least part of bug 149126 sounds like it might be an RPM build problem rather
than x-remote.

bug 112080 could be partially fixed as part of this bug.  either disable
prepending paths to filenames (for consistency's sake) or extend path-prending
both xremote and non-xremote startups.

Comment 28

[Matthias Versen [:Matti]]

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

Comment 29

[Andrew Schultz]

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

Comment 30

[Rembert Oldenboom]

I installed patch v2 and now things work for me. Spawning new mozilla windows
from for instance my mail program doesn't get me in the profile manager anymore.
I don't agree with the assigned severity on this issue. I was already planning
to modify my mail program settings to spawn Netscape 4.7 again. A severity of at
least 'major' would be better IMHO. Anyway, things seem to work now so I don't
really care anymore :)

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[Thorson Little]

Attachment: script after patch is applied

This is a copy of run-mozilla.sh to which the patch has been applied.  I
present it as a service who want this bug-fix but don't want to have to patch
run-mozilla.sh themselves

Comment 33

[Matthias Versen [:Matti]]

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

Comment 34

[Jesse Ruderman]

See also bug 135137, "Profile data cannot be shared by multiple running instances."

Comment 35

[Tet]

Please also see my comments in bug 147160 about problems that any
solution to this bug needs to take into account (specifically,
multiple screens per display, and multiple instances of mozilla
on different machines, displaying on the same X server). I have
encountered both of these problems in real life, so they're not
just theoretical complaints.

Comment 36

[John Marmion]

OpenOffice.org integrates with Mozilla. Please see:

http://www.openoffice.org/issues/show_bug.cgi?id=6391 

The calling of mozilla as an external mailer is what interests me here.
Currently OOo on Windows, when Mozilla is called as the external mailer can
successfully delegate to an already running mozilla process. On Linux and
Solaris, this delegation fails and the user is presented with the choice of
creating/choosing a different profile following the fix for bug #76431.

The patch attached to this bug successfully fixes this issue. The reason for my
comment here is two fold: one to draw attention to the effect on 3rdparty
products such as OOo and also to ask if the delegation works on windows and not
on Linux/Solaris, then why is there no attempt to progress this patch. thanks.

Comment 37

[hacker formerly known as [e-mail]]

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

Comment 38

[Rembert Oldenboom]

Just moved to 1.1b. Unfortunately this bug surfaced again. Solved it by restoring a backup of the previously patched run-mozilla.sh. Why wasn't this patch enforced in the distribution?

Comment 39

[Boris Zbarsky [:bzbarsky]]

See comment 25.  Because it is not considered to be of sufficient quality to
check in.

Comment 40

[Esben Mose Hansen]

I always applies this patch, despite the shortcomings it does have. Since the
locking of profiles has been introduced, I regard this partial solution to be
much better than the current state of affairs. Why not check in the current
patch, and then create a new bug/keep this bug open for further development? No
development for this has taken place for so long, I do not think a new and
better patch is just around the corner. (And it's not even assigned to anyone).
I cannot think of a good reason not to, except that maybe fewer will be
interested in working on the (full) solution to this bug. Please?

Comment 41

[Andrew Schultz]

the shortcomings of the solution here are really shortcomings of XRemote.  the
XRemote issues would be mostly resolved by existing patches in bug 151909 and
bug 149126 (which would also implement a workaround for bug 117114)

Comment 42

[Jo Hermans]

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

Comment 43

[Andrew Schultz]

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

Comment 44

[Rembert Oldenboom]

Attachment: patch v2 for 1.2a

The run-mozilla.sh has changed a small bit with 1.2a, therefore the patch v2
didn't work anymore. Changed the patch file, applied it et voila.

Just copy the patch file to your mozilla dir and type 
cat run-mozilla.sh.patch | patch -p2

Comment 45

[R.K.Aa.]

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

Comment 46

[Lee Harr]

Would it be possible when detecting a previously running instance
of mozilla to also check to see if that instance is "locked up",
"frozen" or "not responding"?

Comment 47

[Andrew Schultz]

in most situations of Mozilla being locked up, the patched version would timeout
and give an error message.

Comment 48

[Esben Mose Hansen]

It's getting tiresome to point to this bug in newsgroup. Could this bug be
pointed to in the Unix release notes?

Also, with a (working) patch, shouldn't this be assigned to the creator?

Comment 49

[Andrew Hagen]

What should the release note say?

Comment 50

[Esben Mose Hansen]

The release notes should say something like:

Due to common problems with profile corruption while using multiple instances of
Mozilla the profile is now locked via. a lock file <profile dir>/lock. This will
prevent Mozilla being launching two instances using the same profile. If you're
used to use this feature, a patch exist which will cause a new window to be
opened from any running instance, while still starting a new instance if none is
found. See (this bug).

But formulated better, probably. The question which is asked so often is:

If I have Mozilla running and click on a link, the profile picker shows up and
informs me my profile is locked. It used to work fine! If I use the -remote
option and Mozilla is NOT open, Mozilla refused to open saying that no open
instance was detected.

Or something along that line. All they need is the patch which is sitting in
this bug and waiting for those other bugs to be patched. For normal, 1-person
use of Mozilla, this patch does all that (at least this) user can ask :-)

Comment 51

[Andrew Schultz]

relnote on a diet:
Profile locking prevents Mozilla launching multiple instances with the same
profile.  A patch exists to detect this condition and open new windows off the
existing process. (bug 122698)

Comment 52

[Esben Mose Hansen]

Yes, a release note like that would fit the bill much better than my stumbling
:). Can anybody get this included?

Comment 53

[Andrew Hagen]

Release notes have their own tracking bug. See bug 175386, where I posted this
revision:

bug 122698 - Opening Mozilla might fail if Mozilla is already running. On some
platforms, not including Windows, profile locking prevents Mozilla from
launching multiple instances with the same profile. A patch is available to
detect this condition and open new windows using the existing process. 

If this needs correction, please comment on bug 175386.

Comment 54

[Torben]

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

Comment 55

[Henrik Edlund]

There is a problem with patch v2 for 1.2a (attachment 101883 [details] [diff] [review]) on Solaris. If I
remove "function " from the function definition it works. Then the function
definition also looks like other ones.

Guess this could be another case of bash-ism from systems where /bin/sh is
/bin/bash something that is not common on Solaris machines.

Comment 56

[Lee Harr]

There should be a way to guarantee that the profile manager is
NEVER DISPLAYED. In my situation, when the profile manager comes
up, the user tries "start mozilla" but that fails because the
profile is already in use (either it is running fine and is just
minimized, or else it is still running in the background but has
no functioning windows -- locked up) So the user tries "create
profile" (a reasonable thing to try) which works... except that
the settings are not correct (there is a web proxy) and so mozilla
is "broken" and I have to go and fix it.

How about this:

If there is a profile called "The Only User" (or something along
those lines) then the profile manager will never be displayed, and
mozilla will do whatever is necessary to get a window open using
that profile.

Comment 57

[Matthias Versen [:Matti]]

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

Comment 58

[shwag]

This feature already worked in Mozilla 1.01.  Its just a new bug for Mozilla 1.1.

Comment 59

[Boris Zbarsky [:bzbarsky]]

Er, no.  This did not work in mozilla.org builds of 1.0.1.

Comment 60

[Andreas Lange]

Attachment: patch v3

Modified version of patch v2. Fixes comment 55, and also handles command line
arguments a bit differently. Patch v2 only checked if the first parameter was a
-mail, -compose or url/file. This version first ignores irrelevant parameters
(like '-splash'), and then goes ahead and checks if it can handle the rest.
Another difference is that it falls through if there is more than one option
left, since we only can pass one parameter with the remote invocation.

I know of at least one site which uses some default options in their scripts
and thus need the part that can strip out these options first.

Comment 61

[Andrew Schultz]

Comment on attachment 107358 [details] [diff] [review]
patch v3

This is a bad idea (at least as implemented here).  I had this disabled
explicitly (as does the RPM script).  There are some parameters that should not
be ignored.  '-CreateProfile', '-version', '-ProfileManager' and '-P' are the
best examples.	Others exist.  The problem is that in order to do this, the
script needs an exhaustive list of parameters to 1) ignore, 2) use and 3) drop
X-Remote functionality.  Everytime the commandline features change, the script
would have to be updated.

The best chance of getting this bug fixed is to have a patch that changes as
little of the current (correct) functionality as possible.

Comment 62

[Andreas Lange]

Oh, I bet it could be implemented better, or disregarded completely, bad I had
to suggest it. :)

Consider the commandline '-mail -P another_profile'. Patch v2 will find '-mail'
as the first parameter and go ahead with the current session ignoring the
requested profile. That is bad, and goes against the spec in comment 61 what may
not be ignored. The same case with patch 3 will fall through to applauncher as
it should.

The main reason for the third patch is that it uses xremote _only_ when it is
really sure it can handle all command line arguments. An unknown parameter or
too many and it will fall through to the standard applauncher. It needs to be
kept in sync of which of applauncher's parameters xremote can handle, but that
goes for any patch handling this problem, right?

The parameter-stripping came as a bonus - I don't think that any more options
than '-splash' can be ignored safely except on a per site basis. So if one has
an ignorelist, it will probably almost never change in CVS. One might like to
change it in local installations though.

Comment 63

[Andrew Schultz]

Attachment: patch v4

> Patch v2 will find '-mail' as the first parameter and go ahead with the
current 
> session ignoring the requested profile.

DOH!  (thanks for pointing this out)
ok, here's a patch that fixes that case, and actually makes the logic simpler.

Comment 64

[Andrew Schultz]

Attachment: patch5

if there's not already an instance of Mozilla the script should exit after
running mozilla...

Comment 65

[Senji]

To add to Tet's comment, it also needs to deal with the case where mozilla is
being run on the same machine but on two different DISPLAYs.

Comment 66

[Andrew Schultz]

It is impossible to run one instance of Mozilla on multiple displays (with or
without this bug).

Comment 67

[Boris Zbarsky [:bzbarsky]]

I think the idea is that there may be _multiple_ instances of Mozilla owned by 
the _same_ user running on _multiple_ displays.

Comment 68

[Andrew Schultz]

> I think the idea is that there may be _multiple_ instances of Mozilla owned by 
> the _same_ user running on _multiple_ displays.

then you need multiple profiles or bug 135137.  fixing this bug won't help with
that situation.

Comment 69

[Vincent Lefevre]

or alternatively, what is proposed in comment 65 could help, and this is (RFE)
bug 125482.

Comment 70

[Andrew Schultz]

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

Comment 71

[Matthias Versen [:Matti]]

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

Comment 72

[Matthias Versen [:Matti]]

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

Comment 73

[R.K.Aa.]

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

Comment 74

[Gilles Durys]

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

Comment 75

[Boris Zbarsky [:bzbarsky]]

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

Comment 76

[Boris Zbarsky [:bzbarsky]]

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

Comment 77

[kirun]

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

Comment 78

[kirun]

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

Comment 79

[Matthias Versen [:Matti]]

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

Comment 80

[hacker formerly known as [e-mail]]

Mass reassign to new default build assignee

Comment 81

[Matthias Versen [:Matti]]

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

Comment 82

[Andrew Schultz]

removing dependency on bug 117114.  the XRemote part of that bug got fixed in
bug 149126.

Comment 83

[Matthias Versen [:Matti]]

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

Comment 84

[Max Polk]

Along the lines of comment #56 "The Only User", my suggested solution is that
during the install, the link /usr/bin/mozilla should be the following short script:

#! /bin/sh

# The installed version of mozilla we are using
mozbin=/usr/lib/mozilla-1.4rc1/mozilla
 
# Ensure we have only zero or one argument
if [ $# -gt 1 ]; then
    echo Usage: mozilla [URL]
    exit 1
fi
 
# See if instance is running
if ! $mozbin -remote 'ping()' 2>/dev/null; then
    # It is not running, start a new instance
    $mozbin "$1"
else
    # It is running, tell it to open the url in a new window
    $mozbin -remote "openurl($1,new-window)"
fi

Comment 85

[Matthias Versen [:Matti]]

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

Comment 86

[James Greis]

This bugs Keywords really need to be updated.

Comment 87

[James Greis]

After Patching run-mozilla.sh (on the latest trunk) with patch5

I get

Error launching browser window: TypeError
Components.classes['@mozilla.org/appshell/component/browser/instance;1'] has no
properties

when trying to launch mozilla. 

Comment 88

[Matthias Versen [:Matti]]

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

Comment 89

[Jamie Zawinski]

Ok, so, I can't really follow what this bug has been about in the past, but
since bug 211504 has been marked as a dup of this, I'll take Matti's word for it...

  - In mozilla 1.3b (and every earlier release), running "mozilla" from the
    shell when mozilla was already running would simply create a new browser
    window.

  - In mozilla 1.4, running "mozilla" a second time gets me into the useless
    profile manager window.

Is there any workaround that will get me the 1.3 behavior back?  Cause otherwise
I'm gonna have to downgrade -- this new current behavior is intolerable.


Mozilla 1.4
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Red Hat 7.3

Comment 90

[wacheo]

[e-mail]:

Earlier versions starts a new instance even if another instance is already
running. This causes problems with bookmarks/mail/etc. because multiple
instances are sharing the same profile. The new behaviour is a workaround to
avoid that.

For the time being, you could use this wrapper script to start mozilla:
   http://kingant.net/?p=mss
Or use the script in the rpm package. (i.e. /usr/bin/mozilla)

Comment 91

[Andrew Schultz]

> In mozilla 1.3b (and every earlier release), running "mozilla" from the
> shell when mozilla was already running would simply create a new browser
> window.

you must have been using an RPM build (or some other non-default release).  the
current behavior has been in place since 1.0.

> Is there any workaround that will get me the 1.3 behavior back?

apply the last patch here (attachment 109199 [details] [diff] [review]) to run-mozilla.sh in your mozilla
directory.

Comment 92

[Matthias Versen [:Matti]]

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

Comment 93

[wacheo]

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

Comment 94

[Matthias Versen [:Matti]]

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

Comment 95

[Tim]

This seems to have nothing to do with building mozilla...
=> XP Apps / Command Line

Comment 96

[Andrew Schultz]

it has even less to do with XP Apps, or command line handling by Mozilla, the
binary.

and if you look at bonsai, you'll note that XP Apps folks don't touch the file
being patched:
http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&dir=mozilla%2Fbuild%2Funix&file=run-mozilla.sh&filetype=match&date=all

back to build config.  might as well be assigned to me.

Comment 97

[Andrew Schultz]

cls: I think this bug may never get fixed if one of the requirements is that it
always does what people expect (stuff like bug 151863), because different people
will expect different behavior in the same situation.  

As such, would an acceptable workaround be to have the xremote sniffing off by
default and have an extra argument to turn it on (or vica versa)?

Comment 98

[Toralf Lund]

I want this, too...

Another thing that might be useful would be support for virtual desktops, a.k.a.
workspaces. I'd prefer opening a new *window* if Mozilla is running, but the
existing window is displayed on a different workspace, new *tab* if it's running
on the same workspace (so I'd generally have one window per workspace, each with
multiple tabs.)

Don't know how easy this is to implement (but Galeon does it...)

Comment 99

[Matthias Versen [:Matti]]

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

Comment 100

[Vincent Valvona]

I have a slight twist on the profile locking mechanism which caused me a lot of grief until I 
stumbled across the solution here, so  I think this is the right place to mention it. 
 
I,m running 1.3.1 on Mandrake Linux, I was working happily away when someone 'pulled the 
mains plug' from the office building. When power was restored, the journaling file system did its 
job and everything was restored and worked fine - except mozilla. Because it had not been shut 
down cleanly, mozilla still thought someonne was using my profile and refused to let me use it. I 
tried creating a dummy profile, switching to that and closing mozilla in the hope that it would clean 
itself up - but it didn't. 
 
I can't remember how I got it to work again the first time that this happened, I may have event 
re-installed mozilla, but the second time I decided that there must be an easier way and 
eventually found (on this page) that there is a lock file in the profile directory (I'd been searching 
for one in the wrong places) and all I had to do was delete it. 
 
My point is, that I'm a software engineer, but I had great trouble in sorting out what turned out to 
be trivial problem - the average user will have no chance. Mozilla either needs to detect when it 
has not been cleanly shut down and clean itself up, or the user should be able to use the original 
profile if they are sure that it is not really in use elsewhere.  
 
Ironically, this is a case of 'deja-vu' as I have recently had similar discussion with the GNUcash 
team which had similar lock problems if it wasn't closed before ending a GUI session. 
 
Vince 
 

Comment 101

[Brian 'netdragon' Bober]

I have a similar thing happen when Mozilla crashes but doesn't get removed from
memory.

do this:

ps -e | grep mozilla

kill -9 _ID_FOR_MOZILLA_

You'll probably see a little question mark on the ps -e listing.


I wonder why this happens, though. I don't know if the kill -9 thing will work
with all cases or if it clears the lock file. I just wanted to mention it
because it sounds similiar. Anyone here know if kill -9 clears the lockfile?

Comment 102

[Brian 'netdragon' Bober]

Oh, and on another note, that wouldn't be a big deal. All we'd have to do, I
imagine, is set something in the profile as the last action before Mozilla
closes. Sort of like unmounting the drives. On startup, it could detect the
unclean close, and ignore any lockfile. We could even do this on every operating
system, and although for now it wouldn't have any result on Windows -- in the
future, it could allow you to perhaps restore a backed-up state if we allowed
saving of browsing state as you browse (another bug somewhere). For now, on OSes
where there are no lockfile, it could just say, "Mozilla was uncleanly exited
last time around", or something like that.

Comment 103

[Brian 'netdragon' Bober]

Say in a debug console message, that is (sorry for the SPAM)

Comment 104

[Christopher Heiny]

To follow up on Comment #102, this [the ability to recover browser state after a
crash or closing] is a very nice feature of Opera that it might be good to
emulate.  However, this might be better discussed as a separate feature request,
rather than in the context of this bug.

Comment 105

[Vincent Lefevre]

The SIGKILL signal can't be trapped, so the lockfile will remain. Of course,
under some conditions, Mozilla can detect that the lockfile is invalid (if the
lockfile contains information such as the hostname and the pid). But it is not
always possible, if Mozilla was executed on a different machine for instance.

Comment 106

[Brian 'netdragon' Bober]

Comment #102
Comment #104

Found the bug: http://bugzilla.mozilla.org/show_bug.cgi?id=19454
"Crash Recovery tracking bug"

Comment 107

[Boris Zbarsky [:bzbarsky]]

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

Comment 108

[hiro protagonist]

with 1.5 running redhat 9 linux, having open office open also means that you
can't open up mozilla at the same time, i'm assuming because open office uses
the mozilla contacts as a potential data source...

sigh

Comment 109

[Matthias Versen [:Matti]]

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

Comment 110

[Joel Aufrecht]

This wrapper script was a life-saver:

--- cut here ---
#!/bin/sh

if mozilla -remote "ping()" 2>/dev/null
then
# Uncomment one of the following lines according to the desired behavior:
# - replace the current page
# - open in new window
location=",new-window"
# - open in new tab
exec mozilla -remote "openURL($1$location)"
else
exec mozilla "$@"
fi
exit 1
--- cut here ---

from
http://crossover.codeweavers.com/pipermail/office-support/2003-April/012632.html.

It would be nice if this behavior was standard, because this bug, which is just
a side-effect of the change to "fix" the shared profile corruption problem, has
probably cost hundreds or thousands of wasted people-hours but would be a quick
fix for a mozilla developer.

Comment 111

[Charles Fenwick]

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

Comment 112

[Joe Infla]

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

Comment 113

[Nicolas Pioch]

Here's what I'd suggest:

When lauching a new mozilla binary:

1st case: Command line parameters explicitely request a new profile
to be used (like calling the profile wizard) -> no ambiguity, proceed

2d case: Command line parameters don't explicitely address whether
the action requested should be performed in a currently running mozilla
or in another copy/profile

In this last case:

- detect via X11 whether another mozilla is already running on the same display
(and/or responsive, if feasible)
If not, let's launch a separate mozilla binary of course...

If another mozilla is already running/detected on the same display:

- open a small window stating:

Another Mozilla is already running, would you like to
* Perform the requested action within the already running Mozilla, or
* Start another Mozilla copy on another profile

[ ] Remember my choice as default value and don't ask me again

(wording to be adapted)

Note that the above logic could be implemented with a program similar
to what "emacsclient" is to "emacs", let's call it "mozillaclient"...
with the added feature that mozillaclient would launch ./mozilla-bin
if a new process/profile is requested.

An additional subtlety might be to address the new window/new tab thing.

I think this dialog might not be the proper place to handle this choice,
but instead a global pref in the current Mozilla profile, something like

When asked to open an http:// URL with X-Remote,
( ) Open URL in new window, or
( ) Open URL in new tab, whenever possible

This should fix the last issue once and for all...

Hope this helps -- Cheers

Comment 114

[Matthias Versen [:Matti]]

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

Comment 115

[Asa Dotzler [:asa]]

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

Comment 116

[R.K.Aa.]

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

Comment 117

[Boris Zbarsky [:bzbarsky]]

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

Comment 118

[Bogdan Stroe]

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

Comment 119

[alanjstr]

There is a script that was checked in for Firefox.  Wasn't it application agnostic?

Comment 120

[Brian 'netdragon' Bober]

alanjstr: Are you referring to the following?

mozilla command loads a firefox window when firefox is open
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122644

Comment 121

[alanjstr]

No, I was referring to bug 177996

Comment 122

[Jeff Walden [:Waldo]]

This was fixed by the previously-mentioned bug 177996 (at least for Firefox,
don't know about Seamonkey).  Consequently, at the very least it should be
minused for 1.0 (if not duped to that bug if it did indeed fix Seamonkey).

Comment 123

[chris hofmann]

thanks for checking up on this jeff...  -minus

Comment 124

[hexbin]

Attachment: Mozilla launcher

Launching this script will start new windows as need.
simple and efficient! :-)

Comment 125

[Andrew Schultz]

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

Comment 126

[Andrew Schultz]

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

Comment 127

[Susan Cox]

I too am having problems and each time I try to get on the internet there is a prompt to choose the user and I get a message saying that account is already in use and have to create a new one every time I get on the internet.

Comment 128

[Mikko Rantalainen]

Attachment: mozilla launch script

Here's the launcher script I use. It correctly detects if given parameter is a real file in the filesystem and if there's already a mozilla/firefox process running. This script also urlencodes the filenames so that you can open files which have characters outside US-ASCII in their filenames. Or, at least it works for me in UTF-8 locale with reiserfs. The last "disown -a" line in the script may require bash version 2 or better and it isn't that important anyway. Feel free to modify for any purpose.

Comment 129

[Joel Caez]

Having the same problem on my 2005101801 build

Comment 130

[Worcester12345]

Just started running into this with latest 12/5 nightly build.

Comment 131

[Andrew Schultz]

Attachment: take the old firefox script

This is mostly what firefox had before the handled this stuff, i.e.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/app/mozilla.in&rev=1.11
(with a few tweaks) plus bug 307185.  So we're picking up some minor FF fixes too (bug 251772, bug 172706).

I also added handling of -compose and -mail, which all the distros do.  XRemote also handles calendar, but I don't know what the normal way to invoke calendar is ("-calendar"?).

Comment 132

[Andrew Schultz]

Attachment: same with -w

The link-sniffing part is easier to see with this.
Also note that the 'moreargs=""' slipped into the previous patch (removed with bug 307185).  It's already out of my local tree.

Comment 133

[[e-mail]]

Comment on attachment 210792 [details] [diff] [review]
same with -w

>+# This is taken almost verbatim from the Mozilla RPM package's launch script.
Well that was a mistake ;-)

> if [ "$OSTYPE" = "beos" ]; then
>-  mimeset -F $MOZILLA_BIN
>+  mimeset -F "$MOZILLA_BIN"
>+fi
This belongs first, then the link sniffer, then the running check.

>+ALREADY_RUNNING=`check_running`
>+
>+################################################################ Parse Arguments
>+# If there's a command line argument but it doesn't begin with a -
>+# it's probably a url.  Try to send it to a running instance.
>+_USE_EXIST=0
>+if [ $ALREADY_RUNNING -eq 1 ]; then
Eliminate all this already running junk. This only need to be
if "${run_moz}" "$MOZ_CLIENT_PROGRAM" -a "${progbase}" 'ping()' >/dev/null 2>&1; then

>+  _optOne="$1"
>+  case "${_optOne}" in
Just use "$1" here.

>+_optLast=
>+for i in "$@"; do 
>+  _optLast="${i}"
>+done #last arg
eval _optLast=\$$#
(what I want is $@ indexed by $#)

>+    # There were "some" command line args.
>+    if [ ${_USE_EXIST} -eq 1 ]; then
>+      # We should use an existing instance, as _USE_EXIST=$_USE_EXIST=-1
>+      exec "${run_moz}" "$MOZ_CLIENT_PROGRAM" -a "${progbase}" "openURL(${_optLast})"
>+      exit $?
>+    fi
This code should be moved to the point that sets _USE_EXIST (which conveniently is also inside an already running check).

>+    # No command line args. Open new window/tab
>+    exec "${run_moz}" "$MOZ_CLIENT_PROGRAM" -a "${progbase}" "xfeDoCommand(openBrowser)"
This code should be moved to inside the previous already running check.

Comment 134

[Andrew Schultz]

Attachment: updated to comments

Comment 135

[[e-mail]]

Comment on attachment 216286 [details] [diff] [review]
updated to comments

>+if [ "$OSTYPE" = "beos" ]; then
>+  mimeset -F "$MOZILLA_BIN"
>+fi

>+MOZILLA_BIN="${progbase}-bin"
> 
>-if [ "$OSTYPE" = "beos" ]; then
>-  mimeset -F $MOZILLA_BIN
Sorry if I confused you with my usage of the word "first" - I only meant for it to go before the link sniffer and already running checks. In particular I don't think it belongs before that assingment to MOZILLA_BIN ;-) r=me with the final patch hopefully ending up with that if being an unchanged line.

Comment 136

[Matt Seitz]

Bug 211505 documents an issue where even the RPM build can cause the Profile Manager to appear if two sessions are opened too close together.  Would fixing this bug also resolve that issue?

Comment 137

[Andrew Schultz]

Attachment: rerearrange beos stuff (-w)

Neil eventually decided he didn't mean link sniffer and that the beos check was ok in the first patch (once the other stuff was fixed).  But AFAICT, the mimeset command would need to do MOZ_CLIENT_PROGRAM there and could do MOZILLA_BIN later when MOZILLA_BIN is actually used.

Furthermore...
The check should be in run-mozilla.sh, not every app's startup script
The check was added due to BeOS bug back in 2001 (bug 66180).  Perhaps the time has come to stop working around it.  I'd guess BeOS firefox users would have had a broken script if this was still a problem.

But I've included a check in this patch for both places.  I'd be happy to remove both.  :)

Comment 138

[Andrew Schultz]

Attachment: rerearrange beos (not -w)

Comment 139

[Matt Seitz]

I see that earlier patches were for "run-mozilla.sh", while the latest patches are for "mozilla.in".  Can the latest patches be run directly against "run-mozilla.sh"?

Comment 140

[Andrew Schultz]

fixing this bug would not fix Bug 211505.  for that bug, the solution would be to not try to start the app a bunch of times.  :)

The most recent patches cannot be applied to run-mozilla.sh.  The cannot even be applied directly to the seamonkey startup script that gets shipped (because of %MOZILLA_BIN% vs. ${MOZILLA_BIN}) although you could hand-patch it.

Comment 141

[Matt Seitz]

(In reply to comment #140)
> The most recent patches cannot be applied to run-mozilla.sh.  The cannot even
> be applied directly to the seamonkey startup script that gets shipped (because
> of %MOZILLA_BIN% vs. ${MOZILLA_BIN}) although you could hand-patch it.

I'm afraid I know very little about the SeaMonkey startup process.  I thought "run-mozilla.sh" was "the seamonkey startup script that gets shipped".  If "run-mozilla.sh"  is not the seamonkey startup script, what is?  Is there someplace where I can learn more about the startup process, so I can learn enough to be able to hand-patch the startup?

Or will a fix be checked in soon, removing the need for me to worry about creating my own patch?

Comment 142

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

The seamonkey startup script is called "seamonkey".

Comment 143

[Andrew Schultz]

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

Comment 144

[jag (Peter Annema)]

... is called "seamonkey", is generated during the build process from source file xpfe/bootstrap/mozilla.in, and does some checks and sets up some stuff before calling run-mozilla.sh, which in turn sets up the environment and runs the executable passed to it, in our case seamonkey-bin. There's some handwaving and skipping over details here, but read those two files if you want to know more.

Comment 145

[jag (Peter Annema)]

Comment on attachment 216951 [details] [diff] [review]
rerearrange beos stuff (-w)

marking r=Neil, adding sr=jag

Comment 146

[Andrew Schultz]

Comment on attachment 216951 [details] [diff] [review]
rerearrange beos stuff (-w)

this is on trunk now

Comment 147

[Andrew Schultz]

marking FIXED (on trunk)

Comment 148

[Johannes Kastl]

As mentioned in <[e-mail]> this one is not working if you use a link to the "seamonkey"-executable.
=====================================================================
../run-affe -> /home/hafi/seam/0604080638-gcc335/seamonkey/seamonkey

hafi@t900:~$ ./run-affe

run-mozilla.sh: Cannot execute
/home/hafi/seam/0604080638-gcc335/seamonkey/run-affe-bin.
=====================================================================
Obviously it gets confused by the name of the link (run-affe) and tries to start run-affe-bin instead of seamonkey-bin

NOTE: Im just writing the comment, I was not the original reporter.

I cannot change RESOLVED to FIXED, as I lack the rights to do so.

Comment 149

[Matt Seitz]

The inablility to launch Seamonkey from (In reply to comment #148)
> As mentioned in <[e-mail]> this one is not working if
> you use a link to the "seamonkey"-executable.
> 
> I cannot change RESOLVED to FIXED, as I lack the rights to do so.

I assume you meant "change RESOLVED from FIXED", presumably to REOPENED.

I'm not sure that reopening this bug is the right response to this issue.  This bug was about detecting a previously launched instance, and that bug has been fixed.  I suggest instead opening a new bug to track the new issue that Seamonkey can now longer be launched from a link.

Comment 150

[Andrew Schultz]

> As mentioned in <[e-mail]> this one is not working if
> you use a link to the "seamonkey"-executable.

Yes.  This is going to bite me too.  Symlinks only work if they have the same as the script.  The alternative is to use a one-line script instead of the symlink.

The binary name could be hardcoded as it was before, but it still wouldn't work properly as invoking the "run-affe" link would attempt to use x-remote to find a running app named "run-affe".

Comment 151

[Johannes Kastl]

(In reply to comment #149)
> I assume you meant "change RESOLVED from FIXED", presumably to REOPENED.

Yes, somehow the old version of my comment got added, in the new one it would have been "resolved fixed to reopenend"

> This bug was about detecting a previously launched instance, and that bug has > been fixed.  

No, it isnt. It does not work, as you can no longer start via symlink. IMHO that is a regression.

Comment 152

[Johannes Kastl]

(In reply to comment #150)
> Yes.  This is going to bite me too.  Symlinks only work if they have the same
> as the script.  The alternative is to use a one-line script instead of the
> symlink.

1. I would not like it if I had naming conventions for symlinks. That is undermining the sense of symlinks IMHO.

2. Symlinks have worked this far, but they no longer do. I would not recommend telling people to change all their symlinks to "one-line scripts"

> The binary name could be hardcoded as it was before, but it still wouldn't work
> properly as invoking the "run-affe" link would attempt to use x-remote to find
> a running app named "run-affe".

Why not look for the executable named xxx-bin in the folder, where the script is running. Then look for remote windows of that command (xxxx-bin or just xxx)? But that is just an idea.

Comment 153

[Robert Kaiser]

Some time ago, we've been jumping through hoops to make symlinks work, IMHO it's unacceptable if we break stuff now like that, actually.

Comment 154

[Andrew Schultz]

I filed bug 333244 for fixing symlink stuff

Comment 155

[Matt Seitz]

(In reply to comment #151)
> (In reply to comment #149)
> > This bug was about detecting a previously launched instance, and that bug has > been fixed.  
> 
> No, it isnt. It does not work, as you can no longer start via symlink. IMHO
> that is a regression.

OK, I'm not familiar with the conventions used on this project.  If a bug is fixed, but later finds that fix has caused a regression in another area, should one:

a) reopen the bug that was marked fixed

b) open a new bug for the regression.  Or perhaps, if the item that regressed had previously been filed as a bug, reopen the earlier bug.

Personally, I prefer b).  I think it allows better tracking of bugs and code changes, and keeps separate bugs separate.  But if the Seamonkey convention is to follow a), then I'm happy to follow that convention.

Comment 156

[Andrew Schultz]

A bug should be reopened only if the bug is not fixed, either because a) the patch that was checked in did not fix the bug, or because b) the patch was backed out.  In case a), the bug is still not reopened sometimes.  For this bug, neither case applies, and I already filed a separate bug.

Comment 157

[Johannes Kastl]

Sorry Guys, I was too fast with writing, and now Im finished with thinking: You are right, this bug is fixed, and another one should be openend (as has been done).

Sorry for the wrong statement in the former comment.

Comment 158

[Matt Seitz]

(In reply to comment #154)
> I filed bug 333244 for fixing symlink stuff

I'd love to see this fix checked in for the SeaMonkey 1.1 branch.  Given that the previous fix causes Bug 333244, how do the logistics work for getting this fix approved for 1.8.1?  Does there need to be a new patch filed here that includes the fix for bug 333244?

Comment 159

[Andrew Schultz]

I've requested 1.8.1 approval for both patches.  I'll commit this and bug 333244 patch when each patch gets approval.

Comment 160

[Matt Seitz]

Thank you for taking the time to answer my questions.  I hope you won't mind one more.  This bug is marked as depending on Bug 112080.  That bug is still open and marked "won't fix". Since this bug was able to be fixed without fixing Bug 112080, should it be removed from the "depends on" list?

Comment 161

[Andrew Schultz]

the dependency list doesn't have to be strictly true... in this case we felt that the issue wasn't sufficiently serious to waiting for a solution (since no such solution might exist) before fixing this.  It will be fixed on trunk (for SM 1.5) when we switch to the "toolkit".  http://wiki.mozilla.org/SeaMonkey:Toolkit_Transition

Comment 162

[Lucia Verona]

I think it might be the same bug, but in Windows, not Linux and it happens in Firefox only after a game involving an applet on Yahoo. In the task manager it doesn't show as a running app, but as an active process. It also occurs in Mozilla, and the profile manager asks me to select/create another profile.

Comment 163

[alanjstr]

No, thats just the process not terminating due to java sucking.