User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030317 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030317 When using the Win32 stub installer, if "too many network errors" are encountered, the install automatically aborts causing you to have to run the installer again (and be faced with bug 77619). However, with some other network failures (I'm not sure what the differences are) the install process is automatically paused - giving the user the option of either resuming or cancelling the process on their own. The "too many network errors" problem should behave similarly to other errors. The user should have the choice of either resuming or cancelling the install - the process shouldn't simply be automatically terminated. If there is some reason WHY it should be automatically terminated then, at the very least, that information should be relayed in the error message (perhaps related to bug 48623) so that the user is made aware of why resume is not being offered as a choice. Reproducible: Always Steps to Reproduce:
I have been running into this lately (3/20 or so). Installer gives this message and quits (commercial and mozilla) If I clean out ns_temp and restart, I get the message-'previous install left some files (WRONG!)do you want to use?' - click no and installation proceeds to completion. Previous installation is not cleaning up ns_temp so subsequent installation is seeing all these files in ns_temp and throwing up the network error message.
Changing severity- I am seeing on every install now- also when the network error comes up, there is no resume ability- I am cancelled. Started to pay more attention to this to see if I was doing anything unusual to prevent TEMP cleanup. Checked TEMP after each install and the xpi files were still there- also found ns_temp1 (assuming left over from previous install as ns_temp had only the xpi files I wanted for last installation) containing xpcom.ns folder
adding to cc list
Installer triage team: need info. Sean to investigate cause of problem and report back in bug.
The problem is that the ns_tempX dirs aren't getting removed at the end of either the GRE or mozilla installations. This might be a cause of xpcom not shutting down properly after the .xpi files have been run. Even though this is in the context of the native installer, I think that this xpcom problem is the same as bug 190816 where mozilla fails to shutdown completely, thus causing the installer to hang. The reason why this could be the same problem is that both mozilla and the native installer uses the same xpcom code. I have a trivial fix to this bug that will "help" alleviate this problem. This fix will not fix the problem with xpcom not shutting down completely, but is still necessary in order to keep the ns_temp dirs cleaned up. Patch coming up.
Created attachment 119894 [details] [diff] [review] patch v1.0 in addition to fixing this bug, this patch also: * moves the check for other instances of mozilla running to before kicking off the GRE installer * checks to see if Netscape is also running. This is necessary because they "could" share the same GRE. And it's necessary to do this because there isn't a way to check to see who's using GRE right now (that problem will be addressed in bug 193173). We just know that it's currently only mozilla and/or netscape (until 3rd party developers start using GRE as well).
Comment on attachment 119894 [details] [diff] [review] patch v1.0 samir is on vacation this entire week. I can get sr= from someone else.
Comment on attachment 119894 [details] [diff] [review] patch v1.0 r=dveditz
Comment on attachment 119894 [details] [diff] [review] patch v1.0 seeking rs= from sspitzer.
Comment on attachment 119894 [details] [diff] [review] patch v1.0 rs=sspitzer, since you have r=dveditz
perhaps the patch from bug 67067 could incorporated
Henrik, I'll try to update and check in the patches from bug 67067.
Comment on attachment 119894 [details] [diff] [review] patch v1.0 This patch has been moved to bug 201309 which is a better bug for this patch. I digressed this bug from it's summary given this patch. I'll attach an (untested) patch relavent to this bug. I'll test it when I get a machine set up appropriately again.
Created attachment 119944 [details] [diff] [review] patch v1.1 I've also increased the number of retries per file before failing to 7 in this patch. I might increase even more given the results of my tests.
Created attachment 120019 [details] [diff] [review] patch v1.2 This patch has been tested. on the 'too many network errors' error message, it will now Pause the download instead of quitting the installer.
Comment on attachment 120019 [details] [diff] [review] patch v1.2 sr=dveditz
installer triage: nsbeta1+/adt3
update: I gave gbush a test build with this patch, and she has informed me that it's working. The installer now goes into pause mode instead of automatically quitting.
Comment on attachment 120019 [details] [diff] [review] patch v1.2 got r=dveditz, seeing rs= from sspitzer
Comment on attachment 120019 [details] [diff] [review] patch v1.2 rs=sspitzer
patch checked in.
tested on build 2003041105- verified temp does get cleaned up (bug 201309) so these errors should not show to verify that pause/resume is available if network errors truly show run installer go to ns_temp directory and modify config.ini file change url for download to non-existent location copy and save all files in ns_temp close installer copy saved files to ns_temp run setup.exe from ns_temp. verify that you are allowed to resume after network error message