When clearing cache after crash, need UI for hang

RESOLVED FIXED in mozilla1.0

Status

()

Core
Networking: Cache
P2
normal
RESOLVED FIXED
17 years ago
16 years ago

People

(Reporter: Mike Pinkerton (not reading bugmail), Assigned: gordon)

Tracking

Trunk
mozilla1.0
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2])

(Reporter)

Description

17 years ago
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

17 years ago
Keywords: hang, nsbeta1

Comment 1

17 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

17 years ago
once we start using the cache block files for data, won't this problem
practically vanish?
(Assignee)

Comment 3

17 years ago
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

17 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

17 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?
(Assignee)

Updated

17 years ago
Priority: -- → P2

Updated

17 years ago
Keywords: nsbeta1+

Comment 6

17 years ago
Removing nsbeta1 nomination because this bug has been plussed.
Keywords: nsbeta1
(Assignee)

Comment 7

17 years ago
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.
Status: NEW → ASSIGNED
Depends on: 81724, 103851
Target Milestone: mozilla0.9.9 → mozilla1.0
(Assignee)

Comment 8

17 years ago
*** Bug 118722 has been marked as a duplicate of this bug. ***

Comment 9

17 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

17 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.

Comment 11

17 years ago
great!  :-)
*** Bug 132327 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Whiteboard: [adt2]
(Assignee)

Comment 13

17 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.
*** Bug 140778 has been marked as a duplicate of this bug. ***
*** Bug 142935 has been marked as a duplicate of this bug. ***

Comment 16

16 years ago
I'm seeing the same behavior in rc3 on Windows 2000.  Was a related fix supposed
to be integrated?

Comment 17

16 years ago
Changing this one to nsbeta1-, since the it depends on bug 81724 which has been
nsbeta1-.
Keywords: nsbeta1+ → nsbeta1-

Comment 18

16 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

16 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

16 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.
Keywords: nsbeta1- → nsbeta1

Comment 21

16 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

16 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 23

16 years ago
No doubt. We probably don't need this bug anymore.

Comment 24

16 years ago
*** Bug 164275 has been marked as a duplicate of this bug. ***

Comment 25

16 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

16 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
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 27

16 years ago
Camiera is on the trunk now.
You need to log in before you can comment on or make changes to this bug.