137978 - QuickLaunch running processes in WinXP prevents installation

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Jaime Rodriguez, Jr.]

Build ID: 2002041306
Reproducible: Always

Steps:
1. Boot WinXP
2. Download stub installer
3. Run Installer

Results: Can't install application. Recieve error "Download of Netscape was
successful. All instances of Netscape 6 must now be closed to proceed to
installation. Select File|Exit from the browser window. then clik OK to install.

Of Note: 
   1. There is no browser to select "File|Exit from ... "
   2. In WinXP (with browser closed) the application is not running in Task
Manager, but *processes* for mozilla are running in the background (i.e.
QuickLaunch). This is different then other versions of Windows, where one can
see , and would expect to quit the application from Task Manager | Applications.
   3. Now the real bad news, "netscp6.exe" uses about 10MB of memory when in QL
mode. Not as big as Explorer's 14MB, but still a huge chunk.

Comment 1

[Jaime Rodriguez, Jr.]

Nominating for nsbeta1, and adding [ADT1] as most new PC these days are running
WinXP, and this would prevent our users (with QL) to install the product.

Comment 2

[Daniel Veditz [:dveditz]]

How can this be adt1 and not nsbeta1+? Over to Curt, though I'm sure this is a
duplicate of the -killAll and other similar bugs. I've been told "File|Exit" was
not intended to quit quick launch, and if that's so then the instructions are
wrong in any case.

Comment 3

[Jaime Rodriguez, Jr.]

Sorry, but I am still in the practice of letting the component teams [+] their
nsbeta1 nominations. <]:^(

Comment 4

[Henrik Gemal]

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

Comment 5

[Jaime Rodriguez, Jr.]

Is this a dupe of the -kill bug?

Comment 6

[Peter Trudelle]

Curt, what is happening with this bug?

Comment 7

[Curt Patrick (gone)]

Sean, this looks like something which might be dealt with in your fix for moz110882?

Comment 8

[Sean Su]

I don't have an XP machine handy, but an educated guess it that the -kill
parameter of mozilla/ns6 is not working properly under XP.

The way the installer does the browser detection is as follows:

  * check for browser
  if (browser detected)
  {
    * call browser with the -kill option to make sure that the
      quicklaunch is disabled.
  }

  * check for browser again
  if (browser still detected)
  {
    * show the dialog that it needs to be shutdown manually before
      installer can continue.
  }

QA, can you try running mozilla/ns6 with quicklaunch enabled but all windows
closed, then from the command line, run it with the -kill parameter.  It
*should* kill the quicklaunch.  If not, then this is where the problem lies.

Bug 110882 does not fix this.  The patch to that bug adds code to shutdown the
browser, but the normal code that calls the -kill is still there and not changed.

Another possibility is that the -kill option, when called, is asynchronous. 
Even though the installer executes it with a wait state, it does not wait.  So
there is a delay() of 2 seconds to allow the -kill to do its magic.  This
delay() of 2 seconds might not be enough under XP and a slow machine.

Jaime, what happens when you clicked on the OK button to continue?  The
installer will go thru the same browser check code and call the -kill again. 
Does it work the second time around?  If so, then the 2 seconds of delay() looks
like the culprit, meaning it's not a long enough delay time.

Comment 9

[Peter Trudelle]

Bill (Law), could you look into possible failure of -kill in this case?

Comment 10

[lchiang]

I believe that I've also run into this on Win2K.
I had filed a bugscape bug because I thought this was commercial only.
http://bugscape.netscape.com/show_bug.cgi?id=14085

I can't say for certain if my bug report is the same as this one although the
date of the two bug reports are close enough and it's a bug that can be seen
right away.

Comment 11

[Grace Bush]

Sean,  

I did a few tests
1. Ran N6 (trunk build from 4/24) with QL enabled and left N6 running as well. 
After download, I got the message to shut down browser- by the time that came,
the QL icon disappeared from systray.  I closed browser and installed

2. Ran N6 with QL enabled but closed N6 before starting download.  After
download-I got the message to close browser at same time QL icon went away.  I
said ok and installed

3. Repeated step 2 and from command line before running installer, I chose
netscp6 -kill which removed the QL icon.

Comment 12

[Grace Bush]

I am also seeing the process from task manager - not sure why Jaime isn't.

Note in Lisa's comment #10, I watched her try to install and NO process was
running in background and the 'please close browser' message could not be
dismissed.  Only by rebooting was she able to proceed. That is WIn2k though.

Comment 13

[scottputterman]

Getting this on the beta stopper list.

Comment 14

[Jaime Rodriguez, Jr.]

This now seems to be WFM (Probably because -kill was checked in last week) if I
wait a while before clicking OK on the dialogue. However, I am getting a crash
now (Pls see the attached talkback report), which startup up Talkback and WinXP
talkback.

Comment 15

[Bill Law]

Curt, I think the problem is that the -killAll starts program termination but 
we are still shutting down when the installer tries to relaunch (with "-
install", I presume).  There is a known timing issue where starting up and 
shutting down in parallel can result in unusual behavior (including crashing).

I will try to go find the code that's doing this and see if that's what's 
happening.  If so, then we may need some delay code, or, code that tests 
whether the shutdown has completed.

Comment 16

[Bill Law]

Well, I don't think the installer is using -killAll.  But the problem still
might be that the already running process is shutting down while the installer
is launching a new one.

But I've also seen a report that it might have something to do with running
other Gecko-based browsers, not the one being re-installed.

Curt, if you need my help, please call.

Comment 17

[Curt Patrick (gone)]

Sean, did you say this would get fixed with your checkin for 110882?

Comment 18

[Sean Su]

Dan and I both think it will fix it.

Comment 19

[Henrik Gemal]

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

Comment 20

[Henrik Gemal]

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

Comment 21

[Sean Su]

bug 110882 's patch has been checked in to both trunk and 1.0.0 branch.  marking
this fixed as well for both.

Comment 22

[Grace Bush]

verifying for both branch (2002050206) and trunk (2002050208)

Comment 23

[Grace Bush]

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

Comment 24

[Grace Bush]

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