Closed
Bug 122597
Opened 23 years ago
Closed 22 years ago
When clearing cache after crash, need UI for hang
Categories
(Core :: Networking: Cache, defect, P2)
Core
Networking: Cache
Tracking
()
RESOLVED
FIXED
mozilla1.0
People
(Reporter: mikepinkerton, Assigned: gordon)
References
Details
(Whiteboard: [adt2])
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.
Reporter | ||
Updated•23 years ago
|
Comment 1•23 years ago
|
||
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).
Comment 2•23 years ago
|
||
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
Comment 4•23 years ago
|
||
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.
Comment 5•23 years ago
|
||
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?
Comment 6•23 years ago
|
||
Removing nsbeta1 nomination because this bug has been plussed.
Keywords: nsbeta1
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. ***
Comment 9•23 years ago
|
||
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.
Assignee | ||
Comment 10•23 years ago
|
||
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.
Assignee | ||
Comment 13•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
I'm seeing the same behavior in rc3 on Windows 2000. Was a related fix supposed to be integrated?
Comment 17•23 years ago
|
||
Changing this one to nsbeta1-, since the it depends on bug 81724 which has been nsbeta1-.
Comment 18•23 years ago
|
||
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?
Comment 19•23 years ago
|
||
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).
Keywords: mozilla1.2
Reporter | ||
Comment 20•22 years ago
|
||
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.
Comment 21•22 years ago
|
||
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.
Comment 22•22 years ago
|
||
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 ?
Comment 25•22 years ago
|
||
Removing "hang" keyword, because this bug is not reporting a hang. Normal severity.
Severity: critical → normal
Keywords: hang,
mozilla1.2
Assignee | ||
Comment 26•22 years ago
|
||
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
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•