122597 - When clearing cache after crash, need UI for hang

Status: RESOLVED FIXED

(Core :: Networking: Cache, defect, P2)

Description

[Mike Pinkerton (not reading bugmail)]

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.

Comment 1

[Simon Fraser [no longer active]]

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

[Darin Fisher]

once we start using the cache block files for data, won't this problem
practically vanish?

Comment 3

[gordon]

mostly, but I think we can find a way to *at least* update the status bar with
something like "clearing disk cache".

Comment 4

[Simon Fraser [no longer active]]

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

[Peter Trudelle]

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

[Jaime Rodriguez, Jr.]

Removing nsbeta1 nomination because this bug has been plussed.

Comment 7

[gordon]

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.

Comment 8

[gordon]

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

Comment 9

[Darin Fisher]

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.

Comment 10

[gordon]

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

[Darin Fisher]

great!  :-)

Comment 12

[Matthias Versen [:Matti]]

*** Bug 132327 has been marked as a duplicate of this bug. ***

Comment 13

[gordon]

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 14

[Matthias Versen [:Matti]]

*** Bug 140778 has been marked as a duplicate of this bug. ***

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 142935 has been marked as a duplicate of this bug. ***

Comment 16

[Eliot Lear]

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

Comment 17

[Jaime Rodriguez, Jr.]

Changing this one to nsbeta1-, since the it depends on bug 81724 which has been
nsbeta1-.

Comment 18

[Ed Grochowski]

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

[Andrew Hagen]

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

Comment 20

[Mike Pinkerton (not reading bugmail)]

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

[Darin Fisher]

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

[Jo Hermans]

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

[Andrew Hagen]

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

Comment 24

[Greg K.]

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

Comment 25

[Andrew Hagen]

Removing "hang" keyword, because this bug is not reporting a hang. Normal severity. 

Comment 26

[gordon]

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.

Comment 27

[Simon Fraser [no longer active]]

Camiera is on the trunk now.