99940 - -kill starts mozilla if turbo mode isn't running

Status: RESOLVED FIXED

(Core Graveyard :: Cmd-line Features, defect)

Description

[Jesse Ruderman]

Running "mozilla.exe -kill" (exit turbo mode) while Mozilla isn't running 
produces a browser window, and if quick launch is enabled, turns it on.  
Running "mozilla.exe -kill" should have no effect in that case.

Comment 1

[timeless]

i'd almost want -kill to bring up a dialog saying:

Mozilla is not already running.
Would you like to disable turbo (preload) for future sessions?
Yes, <Disable>.
No, <Leave it alone>, i was just playing w/ <a href=about:commandline>command 
line parameters</a> because i couldn't get -help to work.

Comment 2

[Mike Young]

Kill shouldn't offer to Disable turbo for later sessions. I thought kill was
just suppossed to shutdown the current instance. In that case, mozilla should
spawn, see that nothing is running and then shutdown. 

Comment 3

[Peter Trudelle]

Bill, do you have a handle on this?  Can you or Terri reproduce it?

Comment 4

[Bill Law]

It's working as designed.  "-kill" was never intended to be anything more than a
means for one to conveniently stop a mozilla that was running in turbo mode.  It
has since been adopted for use by other code that needs to do that (installer,
the systray icon, etc.) and it works for those purposes.

So fixing this shouldn't be a top priority.

Comment 5

[Mike Young]

I disagree, If someone uses this command in... say, a batch script (like me) and
they want to make sure mozilla is closed, they would run mozilla -kill. However,
if mozilla is closed already, boom! up comes mozilla preventing any progress.
Unless there is a way around this problem (I don't know how to poll to see if
Moz is open) there is no way for me to be sure Moz is exited.

Comment 6

[Blake Ross]

When > 1% of our users make their own batch scripts, this bug can become a priority.

Comment 7

[Mike Young]

Batch scriipts are only one of a myriad possibilities that *vendors* could be
using while working with mozilla. Granted, our users may not use -kill all that
often, but as it stands, I know of no way (Short of sending DDE commands) for a
vendor creating an external application that ensures mozilla is off. (Mozilla
needs to be off to make certain changes to chrome, core files, etc.) Especially
if the program runs unattended.

<1% of our users may have this problem, but I'm willing to bet that >1% of our
vendors do. The priority shouldn't be that high, but it should at least be
looked at. (It might be an easy fix) 

Comment 8

[Jaime Rodriguez, Jr.]

Placing "Turbo+" in Status Whiteboard, and marking nsbranch+ for Trudelle's
short list query.

Comment 9

[Bill Law]

Mike,
I don't think "-kill" does that, regardless.  It only turns off turbo mode so
that after all windows are closed, Mozilla terminates.  It doesn't force open
windows to close, nor can it, since if those are mail composer windows, for
example, we'd have to alert the user and give them a chance to Cancel (just like
file|exit does).

Making it so "-kill" doesn't open a new window would be a good thing, just not,
as I said, top priority.

Jaime, I strongly recommend that this *not* be nsbranch+.  This is not an
end-user function and the current behavior is not so broken as to warrant any
attention at this time.

Comment 10

[Jesse Ruderman]

Law, since this bug doesn't affect installer, does that mean installer somehow 
determines whether Mozilla is running before issuing a "mozilla.exe -kill"?

Comment 11

[Blake Ross]

No, in fact, looking at the code, it seems like installer depends on this
behavior; it only runs mozilla.exe -kill upon finishing the install, so if this
was fixed at the moment, Mozilla wouldn't start automatically after installing,
if I read correctly.  This could definitely be cleaned up, but I'm minusing for now.

Comment 12

[Blake Ross]

Actually, nevermind (I think).  Yes, it does detect if Mozilla is open already, 
because it runs -kill as it shows the 'we have detected an instance of 
mozilla....' dialog.

Comment 13

[Bill Law]

See also bug 99828

Comment 14

[Bill Law]

Mass moving bugs that won't get fixed this milestone.

Comment 15

[Bill Law]

balancing move of Helper App Mgt feature work bugs to this milestone

Comment 16

[Bill Law]

Changing summary to reflect new "spec" for -kill.  Note dependence on bug 99848.

Comment 17

[timeless]

If there's a spec for this feature can someone please provide the url to it?

Comment 18

[Curt Patrick (gone)]

I see that there has been quite a bit of discussion on this bug but somehow I've
been missing it.

I don't believe a real spec exists, but here are the requirements for the
installer:  After we download xpi files, if we notice a browser instance
running, we need to get the browser shut down some way so we can install the new
browser.  Our only current option is to ask the user to shut it down.  That is
inconvenient and, in a worse case scenerio, the user may not be able to figure
out how to close all the instances--if the user just clicks on x's sometimes
instances are left running when no visible windows remain--so we really need to
do this for him.

For installer purposes, yes we are checking to determine that mozilla is running
before we call the -kill.  This already works fine as we are doing that
currently so we can turn turbo (which user's would be likely not to think of
doing).  So we don't have the concerns that the batch user has about possibly
running this command-line option when mozilla doesn't even need turned off.

Also, the installer doesn't need any UI to be provided for this by the browser.
 We can do any checks we need to do and provide our own UI based upon what we
find out about the state of Mozilla.

We do, however, want things like Composer and Mail to shut down gracefully,
providing user's a chance to save work in progress and such.

Comment 19

[Bill Law]

timeless: please see http://bugzilla.mozilla.org/show_bug.cgi?id=99940#c16

It's better than nothing :-).  Curt provides a bit more detail.

Comment 20

[timeless]

Law: it's not better than nothing.  My requirement for a spec is a url which is 
always current/correct, eg something on www.mozilla.org. The url you provided 
wasn't correct before it was written here and might not be correct in the 
future.  It's an api change.

Secondly, windows apps are supposed to be able to send and receive a message 
akin to PleaseQuit.  This is sent by the shell when, for example, the user 
decides to logoff.  Is there some reason the installer can't use that message? 
Mozilla should already do the right thing in response to it.

Comment 21

[Peter Trudelle]

re-assigning 'several bugs at once' to [e-mail].

Comment 22

[Gregg Landskov (gone)]

We don't need to change the -kill command.  It is doing what it was intended to
do (exit turbo mode).  What we need is another command line option that will do
the same thing as File|Exit or Ctrl+Q (possibly use -quit, if it doesn't already
exist?).

This option is very important for the installer to key off to ensure that users
don't get stuck with apps open and so that all windows will be shut down
smoothly pre-install.

Comment 23

[Curt Patrick (gone)]

Or, even better than a command-line option would be a Windows system call the
gets trapped by the browser.  I tried the WM_CLOSE message, which windows says
is the right message to use but it didn't seem to get handled.  Bill and I
talked about trying WM_SYSCOMMAND SC_CLOSE, but I haven't been able to get time
to experiment further.

Comment 24

[Peter Trudelle]

Gregg, is that really sufficient?  It will leave QuickLaunch running, in most cases.

Comment 25

[Curt Patrick (gone)]

But we would still have the -kill command-line option as it works currently to
shut down the quick launch, wouldn't we?

Comment 26

[Gregg Landskov (gone)]

That is what I was assuming...the installer already uses the -kill for its
intended purposes, exiting Quicklaunch, and that is already checked in and works
(according to Curt).

So we need to find a final solution for closing down all the windows gracefully
and reliably.  Whatever the best way is, I am all for it.

Comment 27

[Mike Young]

OK, this bug has morphed and people are forgetting the real reason it was filed.

The original bug was that if you use -kill when mozilla isn't running, it will
start mozilla.

This is really a hassle when you use the command to close turbo mode, but the
browser is already closed. if you want a function to close mozilla completely,
that would be wonderful (it would help me with my batch scripts a ton) but I
(and the original intent of this bug) would be content with just having -kill
*not* startup the browser if no instance was running.

Comment 28

[Curt Patrick (gone)]

Maybe the installer hijacked this bug inadvertently.  We really do need a
mechanism for closing the browser, which is what the description of this summary
of this bug seemed to be saying.  In fact, the installer doesn't care about the
behavior if the browser is already closed because we would only be calling this
functionality after determining that we actually need to close the browser. 
We're already making the check anyway.  So maybe we need to open a new bug?

Comment 29

[Peter Trudelle]

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

Comment 30

[Peter Trudelle]

This bug is not morphing, it means exactly what the original report says. If
anyone wants something different, please open a separate bug.  cc law, we need
to get straight on exactly what is needed.

Comment 31

[Mike Young]

OK, per Peter's comments, "morphing is evil", so I'm going to try to repair this
bug back to the way it was before morphing... 

to Netscape Triage Team: This bug was marked nsbeta1+ before it was completely
morphed, but after the original intent. I'm not going to touch it, but we should
determine what part is exactly nsbeta1+

The original intent of this bug was to prevent -kill from spawning a new browser
window when mozilla isn't running. "mozilla.exe -kill" should do nothing when
Mozilla isn't running

The morphed intent of this bug is: -kill should force closure of all open
windows and exit Mozilla. This is now located in bug 132641. 

Comment 32

[selmer (gone)]

Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!

Comment 33

[Curt Patrick (gone)]

I think this should be minused in favor of 132641 which targets the
functionality we really want.

Comment 34

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 35

[Stephen P. Morse]

This bug has been fixed by the patch of bug 132641.