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

VERIFIED FIXED

Status

()

Firefox
Installer
--
critical
VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: dveditz, Assigned: rstrong)

Tracking

(4 keywords)

2.0 Branch
x86
Windows XP
crash, relnote, topcrash+, verified1.8.1.15
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.13 -
blocking1.8.1.15 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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).
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.14?
(Reporter)

Updated

9 years ago
Blocks: 380015
(Reporter)

Comment 1

9 years ago
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.
Flags: blocking1.8.1.13?
Keywords: relnote
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.
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.
Flags: blocking1.8.1.13? → blocking1.8.1.13-
Duplicate of this bug: 426019
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]
Severity: normal → critical
Keywords: crash
Summary: Installer should remove FF3 files in case of downgrade → Installer should remove Firefox 3 files in case of downgrade to avoid crash on start [@ nsACString_internal::Assign][@ xpcom_core.dll]
(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?
Depends on: 428571
No longer depends on: 428571
Even the uninstaller doesn't work after such a downgrade. It quits with an invalid opcode.
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.
Additionally, the uninstaller worked three times today after a downgrade to 2.0.0.13 as well as several other times in the past.
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.
Please try your steps by running the uninstaller via the officially supported method via Add / Remove Programs.
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?
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.
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.
So, performing the steps and installing Firefox 2.0 fixed it whereas performing the steps and installing Firefox 2.0.0.13 did not?
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.
That's fine. Please answer the question in comment #15 there. Thanks
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.
(Reporter)

Comment 19

9 years ago
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.
Flags: blocking1.8.1.15?
Duplicate of this bug: 426219

Comment 21

9 years ago
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

9 years ago
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

9 years ago
Does anybody know how to get your bookmarks back after you deleted these files? My Firefox is useable, but it erased all my bookmarks.
(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/
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.
Flags: blocking1.8.1.15?
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
(Reporter)

Comment 27

9 years ago
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.
Flags: blocking1.8.1.15? → blocking1.8.1.15+
(Reporter)

Comment 28

9 years ago
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.
Created attachment 323936 [details] [diff] [review]
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.
Attachment #323936 - Flags: review?(benjamin)
Whiteboard: [needs r bsmedberg]
(Reporter)

Updated

9 years ago
Attachment #323936 - Flags: review?(benjamin) → review?(ted.mielczarek)
Attachment #323936 - Flags: review?(ted.mielczarek) → review+
Attachment #323936 - Flags: approval1.8.1.15?
Whiteboard: [needs r bsmedberg]
(Reporter)

Comment 30

9 years ago
Comment on attachment 323936 [details] [diff] [review]
patch

Approved for 1.8.1.15, a=dveditz for release-drivers
Attachment #323936 - Flags: approval1.8.1.15? → approval1.8.1.15+
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
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: fixed1.8.1.15
Resolution: --- → FIXED
Created attachment 324105 [details]
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

9 years ago
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.
Keywords: fixed1.8.1.15 → verified1.8.1.15
Duplicate of this bug: 438715

Comment 35

9 years ago
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

9 years ago
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

9 years ago
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. 
Marking verfied as per comment 33.
Status: RESOLVED → VERIFIED

Comment 39

9 years ago
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! 
Please use the links available for support
http://www.mozilla.org/support/

Updated

9 years ago
Duplicate of this bug: 441172

Updated

9 years ago
Duplicate of this bug: 441931
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.
(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.)
Keywords: topcrash+
Yes, I know, what I meant was that the FF20015 perhaps should have gone before the FF3 release.
Blocks: 450504
Crash Signature: [@ nsACString_internal::Assign] [@ xpcom_core.dll]
You need to log in before you can comment on or make changes to this bug.