239722 - Firefox install deletes windows system files

Status: VERIFIED FIXED

(Firefox :: Installer, defect, P1)

Description

[Daniel Veditz [:dveditz]]

toolkit has its own copy of the windows installer, needs its own fix for
potentially system-corrupting bug 236312.

Comment 1

[Daniel Veditz [:dveditz]]

This should probably block 0.9

Most people won't have a problem, but anyone who has installed something
else--especially a windows update--prior to installing Firefox/Mozilla in the
same session is at risk.

Comment 2

[Marcelo Cardoso Martinelli]

This is my account of bug #239722 in my WinXP Home box.
In the same session Firefox (20040403 I think) and ran Windows Update. I don't
recall in what order but it must have been Windows Update first and FF second
from comment #1 above.
After a reboot, before I ever got the login window, I was greeted with a warning
that there was a problem finding SHELL32.DLL. Upon clicking the OK button, the
machine hanged. I rebboted again and chose "My Last Known Good Configuration"
from the login screen, which worked since I was able to login now and didn't get
the warning.
However, after I entered my username and password the system failed to login
properly. I only got the background and the menu bar at the bottom and nothing
else. Mouse pointer moved OK, but it was unresponsive to mouse clicks. My best
guess is that explorer.exe failed to load correctly. I Ctrl+Alt+Del, logged off
and logged back in. This time, no problem.

Comment 3

[Hussam Al-Tayeb]

One question, I just installed 20040405 Firefox/0.8.0+ using official installer.
But there are no pending rename operations found in the registry, will I still
face this bug?

Comment 4

[Daniel Veditz [:dveditz]]

No need to worry then. The corruption happens if there was data already in the
registry from a previous install in the same session.

To save people linking back to the original bug for the scenario
   1. Install something (e.g. windows update) resulting in a
      prompt to reboot/restart the system now
   2. Cancel the prompt, intending to reboot later
   3. Install Firefox (or Mozilla)
Result:
   - Any pending file renames from the first install are converted
     into deletions of the target file. In the windows update case
     these are typically critical windows system libraries.

Comment 5

[Jeremy Hannon]

Recomendation for possible quick-fix, for those that install nightly buids
without paying attention to any build notes.

Just put a test in to see if there are any pending files, and then refuse to
install until the system is rebooted.  It is an old trick, that modern programs
really should have in final, but for an interim fix for nightlies, it would work.

Comment 6

[Arjen Anker]

For everyone who's not sure: just reboot before you install the nightly.

Comment 7

[R Malone]

Re: comment #5:

Recent releases from MS using their Windows Installer sometimes give a message that:
"A previous install has not yet completed. The previous install needs to restart
the computer before it completes. Once this computer has been restarted, please
run this installer again to install product_name."

With a close button only.

This should happen in the Firefox installer if it detects a previous install, as
in comment #5.

Comment 8

[Ali Ebrahim]

camecek, did you think that no one would notice that you set blocking0.9 flag
back to +? If you try it again then someone should probably revoke your Bugzilla
privelidges. As it stands, you're a good candidate for that anyway.

Setting back to blocking0.9?

Comment 9

[Ali Ebrahim]

(In reply to comment #8)
> camecek, did you think that no one would notice that you set blocking0.9 flag
> back to +? If you try it again then someone should probably revoke your Bugzilla
> privelidges. As it stands, you're a good candidate for that anyway.
> 
> Setting back to blocking0.9?

It's probably unclear why I'm being this curt. He's done this before in bug
240367 and has done it again, despite being told not to.

Comment 10

[Mike Connor [:mconnor]]

definitely a blocker, the fix for 236312 is a good start, once there's progress
there we can port the patch in question.  If not, we should have a band-aid for 0.9

Comment 11

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

Boing. 0.9

Comment 12

[Daniel Veditz [:dveditz]]

The revised patch from bug 236312 (attachment 148094 [details] [diff] [review]) will fix Firefox.

Comment 13

[Scott MacVicar]

Attachment: Patch for toolkit from seamonkey patch

Patch against toolkit from
http://bugzilla.mozilla.org/attachment.cgi?id=148094&action=view

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 148446 [details] [diff] [review]
Patch for toolkit from seamonkey patch

This patch caused problems (StrStrI doesn't seem supported on some windows
systems contrary to msdn docs). r-, incorporate the re-fix from bug 243373

Comment 15

[Scott MacVicar]

Attachment: Patch 2

Combined patch from the two bug reports.

Tested under VC++ 6

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 148458 [details] [diff] [review]
Patch 2

The perils of a -w diff (in the other bug) -- you need to indent the block
inside the if(strstr()).

with that change, sr=me fwiw. In toolkit you need a peer r=

Comment 17

[Scott MacVicar]

Attachment: Patch 2 with whitespace fixes

Comment 18

[Mike Connor [:mconnor]]

Comment on attachment 148462 [details] [diff] [review]
Patch 2 with whitespace fixes

kicking this to ben since my installer-fu is weak like little girl, but this
looks to be a straight port of dveditz's patch, so I'm half-inclined to
rubber-stamp this based on having seen all of the review comments in the other
bug

carrying over dveditz's SR

Comment 19

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

Comment on attachment 148462 [details] [diff] [review]
Patch 2 with whitespace fixes

I'm going to rubber stamp thsi since I never modified any of this code in fx's
version so the reviews from the source bug carry over.

Comment 20

[Mike Connor [:mconnor]]

checked in branch and trunk

Comment 21

[Steffen Wilberg]

The branch checkin missed the AVIARY_1_0_20040515_BRANCH.

Comment 22

[Mike Connor [:mconnor]]

checked in on the aviary branch