I run NS6.2 for weeks (yes, weeks) at a time without it crashing. However, when it does crash, the cache is in serious need of cleaning which Necko will do automagically following a crash. This process will start on the first webpage you visit and _lock up the product_ for minutes while it cleans up the cache folder. No UI, no indication of what is going on, just a hang. I had to break in with Sampler to see what we were doing. If I was an end user, I'd think Netscape/Mozilla was broken and would toss the product into my trash can. We really need a UI that explains what is happening.
I agree. I've run into that situation too; it's very scarey. You haar you disk thrashing, Mozilla is locked up, and you wonder if it's chewing away at your system files. I was very tempted to force quit the app (which, of course, would have been even worse for my filesystem).
once we start using the cache block files for data, won't this problem practically vanish?
mostly, but I think we can find a way to *at least* update the status bar with something like "clearing disk cache".
Target Milestone: --- → mozilla0.9.9
I'm not sure I even had a browser window up when I saw this. I think you need to throw some UI, ideally with a progress bar, either a way to cancel, or some message saying that it's not cancellable, and to handle events during this time.
Sounds like some type of message and progress indicator is needed, even if only barber-pole style. I'm not sure about cancel, and expect the implementation would be harder. Even if they could cancel, what would happen on the next page load?
Removing nsbeta1 nomination because this bug has been plussed.
I'd like to reduce the cost of deleting the cache directory (bug 81724) and move the deletion to another thread so it doesn't block the UI (we can use bug 103851 for that). I'll leave this bug open, in case we decide we still want somekind of UI after those are fixed.
*** Bug 118722 has been marked as a duplicate of this bug. ***
gordon: sounds like a great plan to me... of course, while we are clearing the disk cache on a background thread, the user will not be able to load any webpages.... in fact, if they try to do so while we're clearing the disk cache then they will again lock up the UI, since our code will have blocked on the cache service's mutex.
No. The directory to be deleted gets renamed/moved aside, and the thread that deletes it doesn't need any cache service locks. The thread could even consider itself low priority and sleep a bit between file deletions to have minimal impact on the UI.
*** Bug 132327 has been marked as a duplicate of this bug. ***
Initial tests of the fix for bug 81724 show about a 90% reduction in the number of cache files, which will in turn greatly reduce the time required to reinitialize the cache directory at startup after a crash.
*** Bug 140778 has been marked as a duplicate of this bug. ***
*** Bug 142935 has been marked as a duplicate of this bug. ***
I'm seeing the same behavior in rc3 on Windows 2000. Was a related fix supposed to be integrated?
Changing this one to nsbeta1-, since the it depends on bug 81724 which has been nsbeta1-.
Keywords: nsbeta1+ → nsbeta1-
I think the interactive "Clear Disk Cache" function (i.e. "not after a crash") in the Edit->Preferences->Advanced->Cache dialog should also have some kind of user feedback. Caching can take a long time (30 seconds or more), and it is not obvious that it is doing any work. On Windows (where I am running), one should see the hourglass cursor or a progress bar during this operation. Would this be covered by this bug or should a new one be filed which refers to the "non-crash" situation?
As for comment 18, bug 66012 covers the related issue of UI feedback for telling the user that the cache clear operation finished (by graying out the cache clear button).
requesting retriage we are losing users because of this hang. they simply go back to IE because they don't understand what is going on. This can take _minutes_ if you have a large cache and a slow machine.
Keywords: nsbeta1- → nsbeta1
pink: this will be almost entirely fixed by bug 81724... once that bug is fixed we'll create ~ 80% fewer cache files, and i think that'll make this bug fairly minor.
Tested this last night on Mac OS 9 (build 20020807 with the fix for bug 81724) - and clearing the cache was a *lot* faster. I still think we'll need some kind of notification, but the hang is much smaller now. The Mac shows some white-on-black text inside the splash-screen when loading and rebuilding the registry - maybe we put it there ?
No doubt. We probably don't need this bug anymore.
*** Bug 164275 has been marked as a duplicate of this bug. ***
Removing "hang" keyword, because this bug is not reporting a hang. Normal severity.
Severity: critical → normal
Keywords: hang, mozilla1.2
With bug 103851 fixed, there is no hang anymore, so we don't need UI to explain it. When Chimera moves to the trunk, it will pick up this change (and other positive cache changes as well). Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Camiera is on the trunk now.
You need to log in before you can comment on or make changes to this bug.