builds 2000-09-01-10-M18. cross platform (on Linux, it didn't do this the first 2 times). 1. Go to http://jimbob/trigger3.html 2. Press Trigger for Trigger URL field. Don't enter a .xpi. 3. When confirm dialog appears, press OK. Result: On NT, Progress bar starts running, but keeps going and going ... for 1/2 hour last time I checked. On Mac and Linux, the progress bar didn't work. Expected: Check for .xpi when using InstallTrigger method. If not, then timeout should work.
Consider for beta 3, but probably not since webpage authors can work around this.
workaroundable on the webdesigner's side, nsbeta3-
Nominating for rtm. If a wrong URL is triggered, it hangs the XP Confirm dialog. The browser can be used, but it will operate very slowly. For the Mac, see 55567 for what happens when this is followd by a force-quit.
Too much an edge-case for RTM: developers can debug their sites and work around the problem.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
This bug could be used maliciously, plus could be accidental site damage (machine down?). Not in the same class as debuggable script errors that result in a crash, this is more danger to users.
Keywords: nsbeta3 → hang, nsbeta1
Whiteboard: [nsbeta3-][rtm-] → [rtm-]
Over to Don. Necko probably returns some status code in this case that we're not interpreting correctly.
Assignee: dveditz → dbragg
Whiteboard: [rtm-] → [xpibug][rtm-]
Moz 0.9 tasks
Target Milestone: --- → mozilla0.9
This seems to be working now. Marking WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Actually this bug has "migrated". That's why I marked it WORKSFORME. It's not the Confirm dialog that's hanging. The problem is that our OnStopRequest callback gives us the error but we continue to call DownloadNext. (All this is in nsXPInstallManager.cpp) It looks like we clean up ok but obviously something is still happening. Investigating.
Posted patch. Bracketing the Shutdown code and setting mDlg to nsnull after it's been closed, otherwise we try to close it everytime since mDlg->Close() doesn't reset the object to null. Ran 3 tests back-to-back with a bogus ftp path (valid host but invalid path). No crashes and no dialog hangs. Also tried several standard QA tests.
The summary was wrong, if you look at the steps it was always the progress dialog. fixing summary and shortening so it isn't truncated on bug listings
Summary: Triggering w/o specified .xpi results in confirm dlog hanging → Triggering w/missing .xpi results in progress dlog hanging
Created attachment 25887 [details] [diff] [review] New patch using specific shutdown flag instead of mDlg.
Looks good, r=dveditz
Fix checked in yesterday (2/22/01). Should be in today's verification builds.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Build: 2001-03-01-11-Mtrunk(WIN), 2001-03-01-09-trunk(MAC), 2001-03-01-08-Mtrunk(LINUX) Looks good now. However, we are still experiencing a crash in Linux (Bug 70635). Marking this one Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.