crash, relnote, topcrash+, verified22.214.171.124
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).
126.96.36.199 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 188.8.131.52 release? I hope not. The work-around is to completely delete the firefox dir and reinstall -- we should release-note that.
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: blocking184.108.40.206? → blocking220.127.116.11-
Duplicate of this bug: 426019
This bug results in crashes each time Firefox 18.104.22.168 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
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?
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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206, 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 220.127.116.11 did not?
I installed versions 18.104.22.168, 22.214.171.124, 126.96.36.199 and 188.8.131.52 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.
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.
Duplicate of this bug: 426219
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...
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 184.108.40.206 works fine! Thanks Jim!
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 220.127.116.11 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.
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
Yes please, write up a patch for this ASAP. Code freeze for 18.104.22.168 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: blocking22.214.171.124? → blocking126.96.36.199+
qanote: this needs to be verified after fixed, trivially easy to compare files in a "fresh install of 188.8.131.52" vs "FF3 with 184.108.40.206 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)
Attachment #323936 - Flags: review?(benjamin) → review?(ted.mielczarek)
Attachment #323936 - Flags: review?(ted.mielczarek) → review+
Attachment #323936 - Flags: approval220.127.116.11?
Comment on attachment 323936 [details] [diff] [review] patch Approved for 18.104.22.168, a=dveditz for release-drivers
Attachment #323936 - Flags: approval22.214.171.124? → approval126.96.36.199+
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: 188.8.131.52; previous revision: 184.108.40.206 done
Status: NEW → RESOLVED
Last Resolved: 11 years ago
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.
So the crash looks to be fixed in 220.127.116.11. I tried this from RC2 -> 18.104.22.168 and also RC2 -> 22.214.171.124 (which doesn't work). Marking as verified on 126.96.36.199 branch.
Keywords: fixed188.8.131.52 → verified184.108.40.206
Duplicate of this bug: 438715
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 220.127.116.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
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.
Jonathan: This bug is fixed in FF 18.104.22.168 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
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/
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.)
Yes, I know, what I meant was that the FF20015 perhaps should have gone before the FF3 release.
Crash Signature: [@ nsACString_internal::Assign] [@ xpcom_core.dll]
You need to log in before you can comment on or make changes to this bug.