423226 - Installer should remove Firefox 3 files in case of downgrade to avoid crash on start [@ nsACString_internal::Assign][@ xpcom_core.dll]

Status: VERIFIED FIXED

(Firefox :: Installer, defect)

Description

[Daniel Veditz [:dveditz]]

bug 380015 describes a problem where people install a FF2 version on top of a FF3 beta they just tried due to leftover FF3 libraries getting loaded. The FF2 installer should remove these files if found just in case (iirc we did this with later versions of the FF1.5 installer to ease the transition).

Comment 1

[Daniel Veditz [:dveditz]]

2.0.0.14 isn't going to be released until well after beta5, will that be soon enough? How common a crash is this, worth stop-shipping the 2.0.0.13 release? I hope not. The work-around is to completely delete the firefox dir and reinstall -- we should release-note that.

Comment 2

[Robert Strong (they/them - no direct email)]

We've had discussion in the past where people have advocated not doing this so if anyone still thinks we shouldn't please speak up asap.

Comment 3

[Benjamin Smedberg]

I don't think we should do this unless we have a verification pass that the contents of the install directory after the downgrade are the same as a vanilla install... otherwise we're setting ourself up for subtle frankenfox bugs.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This bug results in crashes each time Firefox 2.0.0.13 is started. I got a talkback report (tb43797117Z) with following stack:

Stack Signature	 nsACString_internal::Assign 43f9b2a8
Product ID	Firefox2
Build ID	2008031114
Trigger Time	2008-04-11 10:58:10.0
Platform	Win32
Operating System	Windows NT 6.0 build 6000
Module	xpcom_core.dll + (0003fc51)
URL visited	
User Comments	
Since Last Crash	1 sec
Total Uptime	2 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-Release/WINNT_5.2_Depend/mozilla/xpcom/string/src/nsTAString.cpp, line 231
Stack Trace 	
nsACString_internal::Assign  [mozilla/xpcom/string/src/nsTAString.cpp, line 231]
nsHttpChannel::GetResponseHeader  [mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 3711]
brwsrcmp.dll + 0xe0ac (0x735be0ac)
brwsrcmp.dll + 0xe6e6 (0x735be6e6)
CallTypeSniffers  [mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 698]
CallPeekFunc  [mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 128]
nsInputStreamPump::PeekStream  [mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 140]
nsHttpChannel::CallOnStartRequest  [mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 752]
nsHttpChannel::ProcessNormal  [mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 924]
nsHttpChannel::ProcessResponse  [mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 846]
nsHttpChannel::OnStartRequest  [mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 4017]

Comment 6

[Robert Strong (they/them - no direct email)]

(In reply to comment #3)
> I don't think we should do this unless we have a verification pass that the
> contents of the install directory after the downgrade are the same as a vanilla
> install... otherwise we're setting ourself up for subtle frankenfox bugs.
I don't see a clean way to do this automagically. Would a QA verification suffice?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Even the uninstaller doesn't work after such a downgrade. It quits with an invalid opcode.

Comment 8

[Robert Strong (they/them - no direct email)]

The uninstaller worked for me without any problem after a downgrade. The only way that could happen is if it got corrupted and the installer copies the entire new uninstaller.

Comment 9

[Robert Strong (they/them - no direct email)]

Additionally, the uninstaller worked three times today after a downgrade to 2.0.0.13 as well as several other times in the past.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Robert, I can reproduce it each time with following steps:

1. Install Firefox 3 beta 5 and start Firefox afterwards
2. Install Firefox 2.0.0.13 and start Firefox afterwards
=> Firefox will crash with the given information above
3. Go to installation directory and run helper.exe manually
4. Click 'Next'

When the installer tries to remove the files it stops with the warning: "Installer corrupted: invalid opcode". You have to cancel the uninstaller now. Afterwards you are not able to start the uninstaller anymore.

Comment 11

[Robert Strong (they/them - no direct email)]

Please try your steps by running the uninstaller via the officially supported method via Add / Remove Programs.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Robert, I believe the above tests made my Firefox uninstaller going crazy. No idea what happens to my system but now its enough to only install Firefox 2.0.0.13 and running the uninstallation via the software panel. The mentioned error occurs when the removing of files is started. Shall we better move this issue to a new bug?

Comment 13

[Robert Strong (they/them - no direct email)]

Please try deleting all of the files in your Mozilla Firefox directory, reinstalling 2.0.0.13, and then try to uninstall it from Add / Remove Programs.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That doesn't help. I already removed the files by hand and did a clean re-install, but the issue happened each time. I had to install Firefox 2.0 to get rid of it. I'll try to reproduce it. If I'm able to, I'll file it as a new bug because it doesn't seem to be related to this one.

Comment 15

[Robert Strong (they/them - no direct email)]

So, performing the steps and installing Firefox 2.0 fixed it whereas performing the steps and installing Firefox 2.0.0.13 did not?

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I installed versions 2.0.0.10, 2.0.0.11, 2.0.0.12 and 2.0.0.13 multiple times without success. Each time the same error appears.

Robert, I think we should move our discussion to a new bug.

Comment 17

[Robert Strong (they/them - no direct email)]

That's fine. Please answer the question in comment #15 there. Thanks

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Robert, I'm sorry but after trying to reproduce it I'm not able to within the last hour. Perhaps I'll have more luck within the next days.

Comment 19

[Daniel Veditz [:dveditz]]

A fix would be nice because this is likely to happen to some people, and even a small percentage of our users is a whole boatload of affected people. But not going to block on it.

Comment 21

[Jim Nastic]

It's easy to fix this bug.

1 - After reinstalling Firefox 2.x
2 - Go to ":\Program Files\Mozilla Firefox"
3 - View the files by "Details"
4 - Order by "Date Modified"
5 - Erase all the files (not folders) that were updated last (installed by Firefox 3)
6 - There should be a few files (5 or 6)
7 - Relaunch Firefox 2.x

If someone could provide the name of the files, that would be great... I deleted mine already from the Recycle Bin...

Comment 22

[Denis]

I've deleted following files:
application.ini
blocklist.xml
platform.ini
xul.dll
crashreporter.exe
install.log
mozcrt19.dll
nssdbm3.dll
nssutil3.dll
sqlite3.dll

...and my 2.0.0.14 works fine! Thanks Jim!

Comment 23

[Chris]

Does anybody know how to get your bookmarks back after you deleted these files? My Firefox is useable, but it erased all my bookmarks.

Comment 24

[Robert Strong (they/them - no direct email)]

(In reply to comment #23)
> Does anybody know how to get your bookmarks back after you deleted these files?
> My Firefox is useable, but it erased all my bookmarks.
You can find support links here
http://www.mozilla.org/support/

Comment 25

[Dave Townsend [:mossop]]

At a guess Firefox 2.0.0.15 will be the branch version available when Firefox 3 is finally released, or thereabouts. I realise this is late but I think we should be trying to get this resolved for then.

Comment 26

[Robert Strong (they/them - no direct email)]

Full list of different files

.\application.ini
.\blocklist.xml
.\crashreporter-override.ini
.\crashreporter.exe
.\crashreporter.ini
.\mozcrt19.dll
.\nssdbm3.dll
.\nssutil3.dll
.\platform.ini
.\sqlite3.dll
.\xul.dll
.\components\aboutrobots.js
.\components\browserdirprovider.dll
.\components\brwsrcmp.dll
.\components\fuelapplication.js
.\components\nsaddonrepository.js
.\components\nsblocklistservice.js
.\components\nscontentdispatchchooser.js
.\components\nscontentprefservice.js
.\components\nsdownloadmanagerui.js
.\components\nshandlerservice.js
.\components\nslivemarkservice.js
.\components\nslogininfo.js
.\components\nsloginmanager.js
.\components\nsloginmanagerprompter.js
.\components\nsplacestransactionsservice.js
.\components\nstaggingservice.js
.\components\nstrytoclose.js
.\components\nswebhandlerapp.js
.\components\pluginglue.js
.\components\storage-legacy.js
.\components\txexsltregexfunctions.js
.\modules\debug.js
.\modules\distribution.js
.\modules\downloadutils.jsm
.\modules\iso8601dateutils.jsm
.\modules\json.jsm
.\modules\microformats.js
.\modules\pluralform.jsm
.\modules\utils.js
.\modules\xpcomutils.jsm
.\res\contenteditable.css
.\res\designmode.css
.\res\fonts\mathfontstandardsymbolsl.properties
.\res\fonts\mathfontstixnonunicode.properties
.\res\fonts\mathfontstixsize1.properties
.\res\fonts\mathfontunicode.properties
.\res\html\folder.png
.\searchplugins\wikipedia.xml

note: the search plugin is already handled.

I'm working on a QA semi-automated step for verification

Comment 27

[Daniel Veditz [:dveditz]]

Yes please, write up a patch for this ASAP. Code freeze for 1.8.1.15 is tomorrow (Friday) night, and this probably isn't a true blocker so if it doesn't make it by then we'll punt.

Should be a simple addition to the removed_files list.

Comment 28

[Daniel Veditz [:dveditz]]

qanote: this needs to be verified after fixed, trivially easy to compare files in a "fresh install of 2.0.0.15" vs "FF3 with 2.0.0.15 installed on top".

The franken-browser concerns come up in later versions, say 3.0.1 adds a file, and also if there are any data problems in shared profile files.

Comment 29

[Robert Strong (they/them - no direct email)]

Attachment: patch

I'm also working on a semi-automated way for QA to verify the results of this fix and should have it done shortly.

Comment 30

[Daniel Veditz [:dveditz]]

Comment on attachment 323936 [details] [diff] [review]
patch

Approved for 1.8.1.15, a=dveditz for release-drivers

Comment 31

[Robert Strong (they/them - no direct email)]

Checked in to MOZILLA_1_8_BRANCH

Checking in mozilla/browser/installer/removed-files.in;
/cvsroot/mozilla/browser/installer/removed-files.in,v  <--  removed-files.in
new revision: 1.1.2.21; previous revision: 1.1.2.20
done

Comment 32

[Robert Strong (they/them - no direct email)]

Attachment: HTML page for verification

This page can be used by QA to verify the results of this fix. Save it to your hard drive and follow the instructions on the page.

Comment 33

[Hasham]

So the crash looks to be fixed in 1.8.1.15. I tried this from RC2 -> 1.8.1.15 and also RC2 -> 1.8.1.14 (which doesn't work). Marking as verified on 1.8.1.15 branch.

Comment 35

[Jonathan Snell]

I've never done bug reporting before, so I apologize for my ignorance.

I installed firefox3, then decided i needed to revert for one special add-on that wasn't supported yet. I installed 2.0.0.11 to the same directory and then encountered the same problems people have reported here. 

I wondered if there was something wrong with simply installing ver. 2 to another directory as I have done, as this seems to have fixed the problems, and I didn't lose my bookmarks or anything else. The version of firefox3 however opens as firefox2. 

Also, I noticed someone posted a link to firefox support on getting back your bookmarks, and thought i would post a direct link to the page I found concerning this in support:
http://support.mozilla.com/en-US/kb/Lost+Bookmarks

Comment 36

[Jonathan Snell]

Also, again please forgive me, but... The thread mentioned how this is fixed but when I would click the 'attachment' it only showed a list of files, ones I presumed I was to manually remove. However, I just noticed that this 'patch' was released only a few days ago, and now I am wondering, has this fix been added to the actual newest version of the firefox3 installer, requiring no need for anyone to manually do anything about this problem to fix it now?

If so I feel quite silly.

Comment 37

[Hasham]

Jonathan: This bug is fixed in FF 2.0.0.15 which hasn't been released yet. When it comes out, you should be able to downgrade from FF3 to FF2 with no problems. 

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Marking verfied as per comment 33.

Comment 39

[hagren]

Hey there!

My problem is as follows: I installed Firefox 3 after having removed FF2.0014, and whilst it was basically fine (A bit faster, bookmarks and passwords all still there) it crashed on me on several occasions due to an unknown module multiple times, and I did not really know why (Since then, I updated Java and Flash). I then decided to reinstall FF2, but regardless in which directory I put it (Tried the same first, then "Mozilla Firefox 2")or which version I installed (2.0, 2.00014), now FF2 is similarly unstable as FF3 was for me. FF3 was removed from the get-go, btw, and bookmarks always stayed. What should I do?

Thanks in advance for your help! 

Comment 40

[Robert Strong (they/them - no direct email)]

Please use the links available for support
http://www.mozilla.org/support/

Comment 43

[Martijn Wargers (dead)]

Fwiw, it seems to me this should have been blocking Firefox 3, since there certainly are quite some people that are reverting back to Firefox 2 without uninstalling Firefox 3.

Comment 44

[Samuel Sidler (old account; do not CC)]

(In reply to comment #43)
> Fwiw, it seems to me this should have been blocking Firefox 3, since there
> certainly are quite some people that are reverting back to Firefox 2 without
> uninstalling Firefox 3.

Except there's nothing that could've been easily done at the Firefox 3 level. We're fixing this in 20015. (It's currently topcrash #7 on branch.)

Comment 45

[Martijn Wargers (dead)]

Yes, I know, what I meant was that the FF20015 perhaps should have gone before the FF3 release.