283680 - Firefox in-place update fails

Status: RESOLVED FIXED

(Firefox :: Installer, defect)

Description

[Daniel Veditz [:dveditz]]

For app-update instead of downloading standard .xpis Firefox is attempting to
install via xpi-wrapped native installer (smaller size, for one).

Running Firefox launches the installer, puts entry in xpicleanup.dat to get rid
of the installer.exe eventually.

Scenario I:
----------
If you leave Firefox running the installer eventually gets to a point where it
asks you to click OK to shut down Firefox. If you click the OK button to shut it
down (comes up twice, see bug 283672) then Firefox shuts down, apparently
without launching xpicleanup.exe

[On the side: the shutdown code attempts to pass the "-kill" option to shut down
turbo mode, neither of which is supported by Firefox. A new browser window opens
instead, which is a bit counter-productive if you're trying to shut it down.
Simply need to remove the turbo-killing lines from [Check Instance0] in config.ini]

At the end of the install the new Firefox is launched. It notices the entry in
xpicleanup.dat, gives a shut down/restart message, and launches xpicleanup.exe.

You should be able to restart Firefox now, it's just a bit ugly getting here.

Scenario II:
------------
As above, but instead of letting the installer kill Firefox shut it down
cleanly. xpicleanup.exe is launched to deal with the installer entry in
xpicleanup.dat, but because the installer is still running it hangs around
trying every polling interval.

During the install it finds xpicleanup.exe is in use, so another entry is made
in xpicleanup.dat to finish installing that when the install is over. I don't
think the installer launches another copy of xpicleanup.exe at the end though.

[At this point the xpi script should have returned a "999" status code to the
native installer because the xpicleanup.exe hangup means it couldn't complete,
and the native installer should have put up a message about needing to restart
to complete the install. Not seeing that in Firefox.]

At the end you launch Firefox, which gives the incomplete install message
because xpicleanup.dat exists. It launches another copy of xpicleanup.exe. The
installer goes away so that part of the cleanup can be accomplished, but
xpicleanup can't delete itself so it just hangs around never able to finish. At
this point it should have put a startup entry in the windows registry--if you
reboot everything gets straightened out, but if you keep starting Firefox you
just get the message and more copies of xpicleanup.exe all waiting for each
other to die.

Scenario II is uglier than Scenario I.

Comment 1

[Daniel Veditz [:dveditz]]

The shortest path to success here seems to be

1) update.xpi should delete xpicleanup.exe so it can't be launched in the
beginning of Scenario II

2) update.xpi should launch installer with "-ira" to suppress running Firefox at
the end. This way the installer goes away and can be cleaned up before Firefox
launches and finds the xpicleanup.dat

3) At the end of the browser.xpi install the script manually launches the newly
reinstalled xpicleanup.exe. This will hang around until the installer exits,
then immediately clean it up and get rid of xpicleanup.dat.

4) User launches Firefox and everything works fine, we hope.

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: Something like this for the wrapper script (steps 1 and 2)

Comment 3

[Daniel Veditz [:dveditz]]

Comment on attachment 175577 [details]
Something like this for the wrapper script (steps 1 and 2)

>    var err = execute("firefox-1.0.1.en-US.win32.installer.exe","-ira",false);
>    File.remove(getFolder("Program","xpicleanup.exe"));

Maybe we should swap those lines and remove xpicleanup.exe first. Probably
doesn't matter all that much because we're not blocking on the installer.

Comment 4

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

Attachment: hide launch checkbox when -ira set

Comment 5

[Daniel Veditz [:dveditz]]

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

Comment 6

[Daniel Veditz [:dveditz]]

Comment on attachment 175590 [details] [diff] [review]
hide launch checkbox when -ira set

r=dveditz

Comment 7

[Daniel Veditz [:dveditz]]

Attachment: should do the trick

This patch
 - prevents opening an extra firefox window when trying to kill it
 - increases the delay before we check again from 2 to 5 seconds
 - launches xpicleanup.exe manually if xpicleanup.dat exists
 - fixes an uninitialized variable msvc complained about.

I could not test this, my own builds don't produce a working installer (can't
load the components or initialize the install engine).

Comment 8

[Daniel Veditz [:dveditz]]

checked in on aviary 1.0.1 branch

Comment 9

[Hidehiro Kozawa]

patch left '2 secs' in comment.
        * it's in turbo mode, so we wait 2 secs for it to complete. */
-      Delay(2);
+      Delay(5);

Comment 10

[Daniel Veditz [:dveditz]]

I tested this with the installer from the latest nightly (02-25-19) wrapped up
with the script in attachment 175577 [details].

Worked great in both scenarios: installer goes away cleanly, and when the user
launches the app Firefox comes up fine.

For 1.1 we could bring back the ability to launch the app in this situation if
we wrote a little intermediary program that would do nothing but sleep long
enough for the installer to quit and xpicleanup.exe to remove it, then launch
firefox. But this seems to work fine for now.

Comment 11

[Asa Dotzler [:asa]]

Chase, do you think you could wrap up an installer in the XPI and post it to the
/experimental directory on FTP so that I could point to that and seek out some
more testing on this from the community?

Comment 12

[Chase Phillips]

Comment on attachment 175590 [details] [diff] [review]
hide launch checkbox when -ira set

Retroactively giving approval-aviary1.0.1.  These changes went in for the
respin.

Comment 13

[Chase Phillips]

Comment on attachment 175613 [details] [diff] [review]
should do the trick

Retroactively giving approval-aviary1.0.1.  These changes went in for the
respin.

Comment 14

[Daniel Veditz [:dveditz]]

The wrapper script in attachment 175577 [details] solves the ugly Scenario II problem by
deleting xpicleanup.exe, confidant that the install scripts will replace and
manually launch it.

However, if the install is *cancelled* the user ends up with an equally ugly
problem: http://www.mozillazine.org/talkback.html?article=6159#49

In fact this is probably worse: the Scenario II problem would eventually be
cleaned up by rebooting the machine; with xpicleanup.exe gone there's no way for
the usual to get out of this situation (doing normal user things) without
reinstalling a version of Firefox. If their Firefox is dead they'll need another
browser to download the installer -- a mess. Of course they could just manually
delete xpicleanup.dat (and not worry about the leftover xpinstall.exe in the
temp directory) but they won't know that.

Comment 15

[Asa Dotzler [:asa]]

Dan, isn't that why we dump the installer on the desktop first thing?

Comment 16

[Andrew Poth]

Recent attempts to update-in-place Firefox 1.0 to 1.0.1 and 1.0.1 to 1.0.2
failed on Windows 98SE.  Ended up having to uninstall Firefox both times,
download the full setup file and reinstall.  Unable to provide further details:
 The error message is truncated in the status window when the update fails and I
can't find a way to read the full text of the message.

Comment 17

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

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

Comment 18

[Asa Dotzler [:asa]]

Dan, we're shooting for something better than an xpi wrapped native installer on
the trunk, right? Should we create a new bug and let this one be for the hack we
put on the 1.0 branch?

Comment 19

[Daniel Veditz [:dveditz]]

Yeah, a new bug for the trunk is best. What about linux and mac? I guess for the
branch we're just going to punt.

Comment 20

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

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

Comment 21

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

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

Comment 22

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

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

Comment 23

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

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

Comment 24

[Adam Guthrie]

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

Comment 25

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

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

Comment 26

[William Bumgarner [:zsinj]]

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

Comment 27

[Adam Guthrie]

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

Comment 28

[Adam Guthrie]

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

Comment 29

[Adam Guthrie]

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

Comment 30

[Adam Guthrie]

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

Comment 31

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

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

Comment 32

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

This bug can be closed now that we use a new installer and update system, right?

Comment 33

[Charlie]

The problem also happens with Firefox 2.0.  I'm running Windows Vista and after a reboot of vista or coming out of standby, the browser will not come up.  It just says that the previous installation needs to finish.  I also deleted the cleanup.exe file and it is still happening.

Comment 34

[Vitaly Mar]

I tried Firefox 2.0 on Vista and this bug occured after attempt to install Adobe Flash player. Now each time to run FireFox I get this error message and additional instance of xpicleanup process is started (and newer finished). Maybe somebody from development team can say how to start FireFox, even by manual registry cleaning (I tried all - uninstalling, reinstalling + manual cleaning of xpicleanup does not help)

Comment 35

[Vjacheslav Tataurov]

I have the same problem as Vitaly Mar, but with my own plugin (Firefox 2.0.0.1). The plugin is installed ok on Vista for the first time, but I get the "The program must close to allow..." message after I have installed the plugin. I followed the instructions in the Knowledge Base (http://kb.mozillazine.org/Browser_will_not_start_up) and Firefox starts ok now. BUT my plugin doesn't work anymore - InstallTrigger.getVersion(PLID) returns null and when I try to install the plugin again,I get 211 error. The installation script is simple and works fine on all other operating systems and Netscape7+/SeaMonkey1+/Firefox1+).
I think the problem must be fixed before Jan30 - when Vista will be released.

Comment 37

[Daniel Veditz [:dveditz]]

It's unfortunate that this bug has picked up all the dupes about the post-1.0 update mechanism (note "Version: 1.0 branch"), that's confusing two completely different things. For Vista-specific problems search for bugs with "Vista" in the  status whiteboard or summary.