This one isn't the same as bookmarks being lost on crash/restart. Some users are reporting odd behaviour after installing Firefox 2, including bookmarks being gone. Uninstalling, deleting the install folder and reinstalling makes them reappear. Not sure what the common thread is, but starting this bug now as I've seen 5 reports of this personally.

so, this seems to be fundamental "don't install on top of a running instance" problems. The .exe gets replaced, but none of the DLLs... http://lxr.mozilla.org/mozilla1.8/source/browser/installer/windows/nsis/installer.nsi#188 might be hurting us here?

As a note, at no time am I prompted to stop Firefox (this is in parallels)

I helped someone with this on IRC too. They had been prompted by the installer to close Firefox, they accepted, but it must not have been effective. I got them to do a diff between the dirty install and a clean one, which turned up the same files as attachment 243452 [details]. Mike, what did you mean about the .exe in comment #1 ? firefox.exe is an Error in the log you attached.

Every now and then people are reporting that firefox.exe starts up with their windows and can never be closed (ie starts again). I always suspected malware or FirefoxPreloader running, but ultimately no one wanted to confirm either. This *could* be it.

Two known causes: - Fast user switching with another instance running under a different user - MOZ_NO_REMOTE=1 There are more cases, since at least one person hit this without either of the above being true (on Win2k) Still seems largely scattered, but seems important for 2.0.0.1

I was able to reproduce with the following: - In user profile one, I clean installed 1.5.0.x. Left it running. - Then switched to user profile two. In profile two I installed 2.0. (The installer didn't ask me to shut down the user profile one's 1.5.0.x) Leave it running - Then I return to user profile one and attempt to open the about dialog in 1.5.0.x. I get an XML Parsing Error. In Fact, I get an XML parsing error with Ext. mngr. Bookmark mngr. page setup... basically the 1.5.0.x app in profile one is hosed. In profile two where 2.0 is running, bookmarks are gone.

in user two, I also observed that 2.0 won't shutdown through normal methods. in user one shut down of 1.5.0.x works, then clicking the desktop icon launches the bookmarkless 2.0. it exits fine. back to user two. 2.0 launches but will not close without force quit.

Thanks for the QA! I've got the basics of a patch that uses kill process as a fallback.

This will also need the nsProcess plugin... I'll test this later today

I don't think using kill process as a fallback is a good idea. Biggest reason being then we end up with people who really HAVE lost their bookmarks, and toolbar customizations, and potentially history, etc. It's much easier to instruct people to uninstall and reinstall than it is to walk them through reseting broken rdf files. Second reason, I think it's just generally a better idea to fall back the way software update does "Can't update cuz the process is still running, end the process and try again." The problem isn't that the installer can't end the process, the problem is that the installer isn't detecting the existing process in the first place and prompting people to close it.

That is one of the reasons why I didn't add a kill process in the NSIS installer even though the xpinstall based installer did fallback to using kill process. Since we don't have strings to just ask the user to close the app I am tempted to just add the fallback for 2.0.0.x and have a "You must manually close the app" string for 3.0

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

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

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

Rob, can't we use something like the following in the case where we can't overwrite a file? (Does the NSIS installer check that all files to be installed are indeed writeable before we start writing?) http://lxr.mozilla.org/mozilla1.8/source/browser/locales/en-US/installer/override.properties#85 Also, this doesn't address the spyware-driven unkillable process, since that'll constantly restart, but the only thing we can do there is fail safely.

It checks if the main binary file is in use though not the other files and removes it so the app can't be launched during install. Thanks for pointing out that string. I think I can put something together for the normal case and that will succeed for the spyware-driven case as well.

I have found that the Adobe Acrobat plugin does not always dump the process when Firefox is closed down, even if you use Task Manager and kill the firefox.exe -- you sometimes find that Acrobat.exe is still running in the process list, even if it is not visible on your task bar and even if you do not have the "acrotray" thing running. Perhaps the changes to the Firefox installer can also check to see if any plugins like Acrobat Reader are still running and prompt the user to exit Acrobat as well? Also, another thought: since I am a Webmaster I must have a dozen different browsers installed for testing (but Firefox is my favorite!) anyway, when I installed IE7 it did not register the Acrobat plugin so I had to reinstall Acrobat afterwards to get it to work. Perhaps the same type of thing is happening with the Firefox installer? It might need to go thru the plugin list and re-register all of them...just a thought.

(In reply to comment #17) [ I now have a different email addr if you need to get in touch: tim [at] idahovandals.com -- should have updated my profile before posting previous msg, oh well. ]

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

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

The most recent back up of bookmarks.html was the same size as the 2nd most recent backup (with all of my bookmarks in it!) but was completely blank (tons of space's I suppose). The most recent was a "default" bookmarks (I guess it saw nothing so it made a new one.) I simply copied correct backup (2nd most recent) from: C:\Documents and Settings\{User}\Application Data\Mozilla\Firefox\Profiles\6ug0fnok.default\bookmarkbackups\ to Profiles... Done. Could someone make a small utility for restoring backups? is one planned for a future version... a back up is pointless unless it is available (and easy) to use. (Time Machine!) ============= Windows XP :(

Stephen - you're experiencing a different bug, 284099. You can import bookmarks from a backup using the organize bookmarks manager. changing summary to be a bit more differential between the two, sorry for breaking threading :-\

To add a corroborating account. I installed 2.0 while - unknown to me - another user had 1.5 open, and the installer did not detect this (it has in past with subversion updates) - Things were very bad - On a hunch I checked the other users, closed down FF1.5, switched back and installed 2.0 over - things now appear to be fixed - and my bookmarks haven't gone anywhere.

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

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

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

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

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

From the last dup and from some forum threads, it seems like a lot of people who are seeing the "tabs not working" problems have user agents like "rv:1.8.0.7 ... Gecko/20060909 Firefox/2.0".

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

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

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

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

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

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

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

(In reply to comment #29) > From the last dup and from some forum threads, it seems like a lot of people > who are seeing the "tabs not working" problems have user agents like > "rv:1.8.0.7 ... Gecko/20060909 Firefox/2.0". > I'd be willing to wager that they all have it - it being rv 1.8.0.7 and Firefox/2.0. In any case, if you see such a user agent, then that user has encountered the install issue.

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

Just upgraded from 1.5 to 2.0, browser restarts and voila - all bookmarks gone!! Win XP Pro, SP2.

charlie - thanks, I said that already. If you read the rest of comment #0 you'll see the simple steps you need to follow to get them back. If that doesn't work for you then you'll want to read the support page at http://kb.mozillazine.org/Lost_bookmarks

I ran 3 separate tests several thousand times each using terminate process without losing my bookmarks. 1) launch app and terminate process. 2) launch app, nav to a web page and add it to bookmarks root, nav to another web page and add it to bookmarks root, and terminate process. 3) launch app, nav to a web page and add it to bookmarks toolbar, nav to another web page and add it to bookmarks toolbar, and terminate process. I'm going to run it over night again while testing #3 and if I don't lose bookmarks I'm going to use this method which was also used by the xpinstall based installer as a last resort for the case where we don't have the message window registered unless someone comes up with a reason not to.

I ran the following test using my main profile over night again successfully so I am going to go with this approach as the fallback to fix this bug 3) launch app, nav to a web page and add it to bookmarks toolbar, nav to another web page and add it to bookmarks toolbar, and terminate process

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

Test -- Test -- Test

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

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

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

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

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

In addition to (1) Make the installer more effective at killing existing Firefox processes I think we should also (2) before writing anything, make sure the DLLs can be overwritten, or try to overwrite a DLL first. If the DLLs can't be overwritten (despite attempts to kill all Firefox processes), show an error message and stop the installation process. (3) show an error message if something goes horribly wrong halfway through the install, so users who hit nasty installer bugs won't be surprised when Firefox doesn't work any more and will be able to submit useful bug reports.

Rob - I still think killing the process is wrong. The updater does the right thing, it tells the user rather than killing it itself. We shouldn't be killing processes from other xp accounts. I think comment #15 is on the money. Also, in your tests have you been browsing to pages using the bookmarks and then killing the process? And are you forcing closed a process that won't end on it's own? I respect that you haven't been able to reproduce this, but the fact that so many bug reports exist on the rdf corruption does show how many people DO hit it.

(In reply to comment #51) > Rob - I still think killing the process is wrong. The updater does the right > thing, it tells the user rather than killing it itself. We shouldn't be > killing processes from other xp accounts. I think the best approach would be to detect this condition before the install touches any files and refuse to install if a Firefox process owned by another user is running. Killing processes owned by other users is not the proper thing to be doing IMHO. But, obviously, permitting the installer to run and install some files and not others is wrong as well.

(In reply to comment #52) > I think the best approach would be to detect this condition before the install > touches any files and refuse to install if a Firefox process owned by another > user is running. Killing processes owned by other users is not the proper > thing to be doing IMHO. Yes, this is how the updater functions. If a process is still running it aborts install and informs the user.

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

(In reply to comment #53) > Yes, this is how the updater functions. If a process is still running it > aborts install and informs the user. > You misunderstood what I was trying to say. Obviously checking to see if the process is running is NOT sufficient, otherwise this bug would not have been filed. After it is done with its checking to see if the app is running, it needs to then attempt to write the firefox.exe file and if that fails abort the install. Checking to see if the application is running will not work on a multi-user installation if the user does not have sufficient priviledges to see processes other than his/her own.

There are a couple of different NSIS plugins available for terminating the process. I am leaning towards using this one. http://nsis.sourceforge.net/NsProcess_plugin I think it is best if we recompile it since malware authors use these plugins as well and anti-virus vendors will often use the plugin signature to determine if the exe is malware. http://forums.winamp.com/showthread.php?threadid=255993

Help! I suffer the same issue here on my pc... had mozilla 1.5.0.7 installed, upgraded to 2.0, since then my bookmarks got lost! I tried to completely uninstall version 2.0 and reinstall it... didn't work. Funny thing is, that I can import my old bookmarks and have them then until I shutdown/restart mozilla, after that they're lost again! Help, anybody a good advise... I get crazy here! Thanks

Comment on attachment 245491 [details] [diff] [review] patch >Index: browser/installer/windows/nsis/installer.nsi >=================================================================== >RCS file: /cvsroot/mozilla/browser/installer/windows/nsis/installer.nsi,v >retrieving revision 1.3.2.16 ... >+; NSIS provided macros that we have overridden >+!include overrides.nsh >+!insertmacro LocateNoDetails >+!insertmacro TextCompareNoDetails This should be after the NSIS provided macros and before the custom macros so I moved it >@@ -180,29 +182,43 @@ ... > ClearErrors > ${CloseApp} "true" $(WARN_APP_RUNNING_INSTALL) > ; Try to delete it again to prevent launching the app while we are > ; installing. >- ${DeleteFile} "$INSTDIR\${FileMainEXE}" > ClearErrors >+ ${DeleteFile} "$INSTDIR\${FileMainEXE}" >+ ${If} ${Errors} >+ ClearErrors >+ ; Try closing the app a second time >+ ${CloseApp} "true" $(WARN_APP_RUNNING_INSTALL) >+ retry: >+ ClearErrors >+ ${DeleteFile} "$INSTDIR\${FileMainEXE}" >+ ${If} ${Errors} >+ ; Fallback to the FileError_NoIgnore error with retry/cancel options >+ ${DisplayCopyErrMsg} "${FileMainEXE}" >+ GoTo retry >+ ${EndIf} >+ ${EndIf} Try to close the app exe two times and if that fails fall back to the copy file error. >@@ -650,44 +666,55 @@ ... > Function CopyFile > StrCpy $R3 $R8 "" $R2 >+ retry: >+ ClearErrors > ${If} $R6 == "" > ${Unless} ${FileExists} "$R1$R3\$R7" > ClearErrors > CreateDirectory "$R1$R3\$R7" > ${If} ${Errors} > ${LogMsg} "** ERROR Creating Directory: $R1$R3\$R7 **" >+ ${DisplayCopyErrMsg} "$R7" >+ GoTo retry > ${Else} > ${LogMsg} "Created Directory: $R1$R3\$R7" > ${EndIf} > ${EndUnless} > ${Else} > ${Unless} ${FileExists} "$R1$R3" > ClearErrors > CreateDirectory "$R1$R3" > ${If} ${Errors} > ${LogMsg} "** ERROR Creating Directory: $R1$R3 **" >+ ${DisplayCopyErrMsg} "$R3" >+ GoTo retry > ${Else} > ${LogMsg} "Created Directory: $R1$R3" > ${EndIf} > ${EndUnless} > ${If} ${FileExists} "$R1$R3\$R7" > Delete "$R1$R3\$R7" >+ ${If} ${Errors} >+ ${DisplayCopyErrMsg} "$R7" >+ GoTo retry >+ ${EndIf} > ${EndIf} > ClearErrors > CopyFiles /SILENT $R9 "$R1$R3" > ${If} ${Errors} >- ; XXXrstrong - what should we do if there is an error installing a file? > ${LogMsg} "** ERROR Installing File: $R1$R3\$R7 **" >+ ${DisplayCopyErrMsg} "$R7" >+ GoTo retry Display an error msg that allows the user to cancel the install if we can't copy a file into the install location. >@@ -990,24 +1017,36 @@ ... >+ ; Try to close the app if the exe is in use. > ClearErrors > ${If} ${FileExists} "$INSTDIR\${FileMainEXE}" > ${DeleteFile} "$INSTDIR\${FileMainEXE}" > ${EndIf} > ${If} ${Errors} > ClearErrors > ${CloseApp} "false" "" >+ ClearErrors > ${DeleteFile} "$INSTDIR\${FileMainEXE}" >+ ; If unsuccessful try one more time and if it still fails Quit >+ ${If} ${Errors} >+ ClearErrors >+ ${CloseApp} "false" "" >+ ClearErrors >+ ${DeleteFile} "$INSTDIR\${FileMainEXE}" >+ ${If} ${Errors} >+ Quit >+ ${EndIf} >+ ${EndIf} This is for silent installs >Index: browser/installer/windows/nsis/uninstaller.nsi >=================================================================== >RCS file: /cvsroot/mozilla/browser/installer/windows/nsis/uninstaller.nsi,v ... >@@ -359,18 +359,25 @@ >- ${DeleteFile} "$INSTDIR\${FileMainEXE}" > ClearErrors >+ ${DeleteFile} "$INSTDIR\${FileMainEXE}" >+ ${If} ${Errors} >+ ClearErrors >+ ${un.CloseApp} "true" $(WARN_APP_RUNNING_UNINSTALL) >+ ClearErrors >+ ; Try one more time and if that fails uninstall what ever we are able to. >+ ${DeleteFile} "$INSTDIR\${FileMainEXE}" >+ ${EndIf} Try one more time on uninstall and then continue on as usual >Index: toolkit/mozapps/installer/windows/nsis/common.nsh ... >@@ -954,56 +954,78 @@ ... > !macro CloseApp > > !ifndef ${_MOZFUNC_UN}CloseApp > !verbose push > !verbose ${_MOZFUNC_VERBOSE} > !define ${_MOZFUNC_UN}CloseApp "!insertmacro ${_MOZFUNC_UN}CloseAppCall" > > Function ${_MOZFUNC_UN}CloseApp > Exch $R9 > Exch 1 > Exch $R8 > Push $R7 >+ Push $R6 > > loop: >- FindWindow $R7 "${WindowClass}" >- IntCmp $R7 0 end >+ Push $R6 >+ nsProcess::_FindProcess /NOUNLOAD "${FileMainEXE}" >+ Pop $R6 >+ StrCmp $R6 0 0 end Check if the process is running instead of the window class >+ FindWindow $R7 "${WindowClass}" >+ IntCmp $R7 0 +4 > System::Call 'user32::PostMessage(i r17, i ${WM_QUIT}, i 0, i 0)' > # The amount of time to wait for the app to shutdown before prompting again Try closing with the window class first >- Sleep 4000 >+ Sleep 5000 >+ >+ Push $R6 >+ nsProcess::_FindProcess /NOUNLOAD "${FileMainEXE}" >+ Pop $R6 >+ StrCmp $R6 0 0 end >+ Push $R6 >+ nsProcess::_KillProcess /NOUNLOAD "${FileMainEXE}" >+ Pop $R6 >+ Sleep 2000 Terminate the process if it is still running >+/** >+ * Displays a error message when a file can't be copied. >+ * >+ * $0 = file name inserted into the error message >+ */ >+!macro DisplayCopyErrMsg Helper for displaying the copy file error message with retry cancel options

Ooops... forgot a change to makensis.mk

Bill - I understand what you're saying. The installer has not been checking for a running process in the same way as the updater. The updater can tell if another xp profile has a running process, the installer does not. This is not a problem with the updater, therefore the updater is a) doing it differently and b) I believe doing it correctly.

(In reply to comment #58) > Help! I suffer the same issue here on my pc... had mozilla 1.5.0.7 installed, > upgraded to 2.0, since then my bookmarks got lost! I tried to completely > uninstall version 2.0 and reinstall it... didn't work. Funny thing is, that I > can import my old bookmarks and have them then until I shutdown/restart > mozilla, after that they're lost again! Help, anybody a good advise... I get > crazy here! Thanks > Chris- you're not seeing this bug then, you're seeing 319196

In relation to Bill's comment one symptom is updater bug 340535.

So.....? What's the solution to this mess? I'm getting to the point where I wish I hadn't heard of Mozilla... I can't play with the code, so what is my option??? Delete it and reinstall - go back to Explorer..?

So..? What do we do about it? I'm considering dumping Mozilla - the cause of my disaster!

jkjroach - the user solution to this issue is incredibly simple and already mentioned in the bug. Uninstall firefox 2, make sure there are no firefox.exe processes running and install firefox 2 again. If you still have issues after this, then you are not experiencing this bug and should seek support.

Hey all, I have an even larger problem. The add/remove programs module started to hang after the new install. Now I can't even uninstall the new release to start again. Add that to bookmarks that don't work, type ahead that doesn't and other weird behaviour I'm going over to the darkside. I love Firefox but man what a pain. As a non-techie this has not been a good experience. I'm really stuck - if anyone has any ideas I'd love to hear it. Good luck to us all.

If you are not seeing this issue, please file/find an appropriate bug. Best bet is to seek support first so you know whether you've actually found a bug or if something just went weird for you. #firefox in irc.mozilla.org or forums.mozillazine.org Ron - then don't uninstall first, you can just install again or delete the program files before installing again, let us know what happens.

Hi All, Thanks for trying to help. I used the uninstall to no avail. Same issues even after deleting everything except the .exe file plus a couple of others that wouldn't delete. Still have the same problem with the add/remove program xp module. Very puzzling and frustrating.

I reported a bug and it said the one I reported was a duplicate of this one. But from what I'm reading it's not. My bookmarks are not missing and tabs are not broken. After I installed Firefox 2 it just started freezing randomly. I click a link it freezes, I open a web page it freezes, I open a new tab it freezes. And it does it randomly too; I can be on Firefox for hours without any problems or just a minute. I also know it's not the websites I visit because I usually go to the same ones and Firefox freezes no matter what site I'm on. Is it the same problem?

(In reply to comment #71) > Is it the same problem? We believe so. Please see Comment #23 for a workaround.

Well, actually, no. Leala's bug 359458 lacks a broken UA string, and is much more likely to be an extension bug.

(In reply to comment #72) > (In reply to comment #71) > > Is it the same problem? > > We believe so. Please see Comment #23 for a workaround. > Because of the nature of this bug, I don't think there are real variations to how people are affected. If the bookmarks aren't missing, then I don't believe it can be the same issue.

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

Comment on attachment 245493 [details] [diff] [review] patch - includes makensis.mk change r=sspitzer, thanks for the detailed patch walk through yesterday, rob.

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

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

how do i install the patch???

(In reply to comment #79) > how do i install the patch??? You don't. The work-around is 1, Uninstall Firefox 2 2, Delete everything in the firefox install dir (probably C:\Program Files\Mozilla Firefox) except the plugins directory 3, Re-install Firefox 2

ok i uninstalled firefox 2.0, and i am left with 10 dlls that wont delete and firefox.exe the dlls are -js3250 -nspr4 -nss3 -plc4 -plds4 -smime3 -softokn3 -ssl3 -xpcom_compact -xpcom_core should i leave them and reinstall 2.0 or is there something else i should do, the exe that is left is for firefox 1.8

Restarting Windows should make it possible to delete those files. Or you can install Firefox 2 into a different directory.

(In reply to comment #81) > ok i uninstalled firefox 2.0, and i am left with 10 dlls that wont delete and > firefox.exe > > the dlls are > > -js3250 > -nspr4 > -nss3 > -plc4 > -plds4 > -smime3 > -softokn3 > -ssl3 > -xpcom_compact > -xpcom_core > > should i leave them and reinstall 2.0 or is there something else i should do, > the exe that is left is for firefox 1.8 > Open task manager and check to see if firefox.exe is listed in the *processes* tab. If it is, highlight it and choose end process. If the process ends, continue with uninstalling and reinstalling firefox. If the process ends but comes back you have a trojan.

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

I was the last dupe - I did in fact check to see whether my issue had been reported, but didn't find this bug. Probably because I was looking for a different set of symptoms. I discovered the cause of the problem (1.5 process in a different user account) and the fix (kill the process, uninstall, reinstall) myself. But after I finished the fix, Windows XP was rendered unbootable. It died with a blank blue screen at the point where it usually offers a log in screen. Hosing the host OS is just generally bad. This is definitely the same issue - just thought I'd point out that in some cases there are consequences more severe than a malfunctioning browser. See the write up in Bug 361713 if you want the gory details.

Checked in to trunk

Rob, is this something that can be unit-tested? Please set the in-testsuite flag accordingly.

Please request branch approval if this patch OK as-is, or attach a branch-version and request approval on that.

Comment on attachment 245493 [details] [diff] [review] patch - includes makensis.mk change approved for 1.8 branch, a=dveditz for drivers

I'll land this afternoon

Checked in to branch

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

Robert, would it suffice to use the steps in comment #6 to verify this fix?

When using the steps in comment #6 you will get prompted to close the app and if you click OK it will try to close the app and chances are it won't succeed and will prompt again. We'll get better strings for this for 3.0 so it explains that the user will need to close the app manually. In the case of using MOZ_NO_REMOTE in the same profile it will succeed in closing the app if OK is clicked.

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

for testing bugs system