Closed Bug 998445 Opened 10 years ago Closed 10 years ago

Unable to see disk cache size, "Calculating web content cache size…" stays forever

Categories

(Core :: Networking: Cache, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla31
Tracking Status
firefox31 + fixed

People

(Reporter: dao, Assigned: mayhemer)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

I'm unable to see the disk cache size in Firefox's Network pref pane. It just says "Calculating web content cache size…" for minutes until I get tired and close the dialog.
Are you using the new HTTP cache v2 (browser.cache.use_new_backend at 1) ?

In case of the new cache: Is it really minutes?  When your cache contains only few files, we build the index after some 50 seconds after startup and don't persist it (you may want to ask Michal for more details here).  

We need an API to push the build happen sooner when cache capacity is about to show as well as for about:cache (I'll file a bug).  But if that is actually _minutes_ you don't see a change, then the problem is somewhere else.

Can you please provide some more information like if there is something in the browser error console or so?  This bug report doesn't say much, for me the UI works in both cases (cache v1 and cache v2).
Flags: needinfo?(dao)
(In reply to Honza Bambas (:mayhemer) from comment #1)
> Are you using the new HTTP cache v2 (browser.cache.use_new_backend at 1) ?

Nope.

> Can you please provide some more information like if there is something in
> the browser error console or so?

I opened the browser console, then the pref window but saw no error reported.
Flags: needinfo?(dao)
I'd like to ask you for two separate tests:

1. 
- in about:config please switch browser.cache.use_new_backend to 1 (no need to restart) 
- then open the prefs dialog again
- does it show "0 bytes" consumption (after no longer then those 50 seconds mentioned in comment 1) or is it still stuck?

2. 
- please install a build from (just pushed..) https://tbpl.mozilla.org/?tree=Try&rev=c86a3c676e9b
- switch browser.cache.use_new_backend to 0 (it's at 1 by default for that build)
- try again the options dialog

Thanks!
Flags: needinfo?(dao)
Dão, here is (will be) a functioning build: https://tbpl.mozilla.org/?tree=Try&rev=eb5026e8fd8f
I got "0 bytes" in both tests.
Flags: needinfo?(dao)
(In reply to Dão Gottwald [:dao] from comment #5)
> I got "0 bytes" in both tests.

Thanks!
Ah... how 0 bytes in both cases?  Did you switch browser.cache.use_new_backend to 0 when checking with the try build?
(In reply to Honza Bambas (:mayhemer) from comment #7)
> Ah... how 0 bytes in both cases?

How would I know? :)

> Did you switch browser.cache.use_new_backend to 0 when checking with the try build?

yes
(In reply to Dão Gottwald [:dao] from comment #8)
> (In reply to Honza Bambas (:mayhemer) from comment #7)
> > Ah... how 0 bytes in both cases?
> 
> How would I know? :)

:)  It just surprises me.  Here's why: I assume the profile you report this for is your daily profile, and you are using the cache so that there is something in it - should not be 0 bytes.  Is that so?  Or do you have any special settings for cache preferences?
Now that you mention it, I do have this profile configured to clear the cache on shutdown.
(In reply to Dão Gottwald [:dao] from comment #10)
> Now that you mention it, I do have this profile configured to clear the
> cache on shutdown.

Aha!  But the problem with the UI having stuck is gone, that's the important part.  I think I'll separate the patch you have tried to this bug.

Thanks for help!
Attached patch v1 (obsolete) — Splinter Review
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Attachment #8409362 - Flags: review?(michal.novotny)
- ripped from patch v0.1 at bug 916052
- using directly the old visit API
- result is nsICacheDeviceInfo.totalSize in VisitDevice for the "disk" device

This should go to the tree ASAP since we broke this with the recent UI patch, must not slip to the m-a channel.
Comment on attachment 8409362 [details] [diff] [review]
v1

Review of attachment 8409362 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with following fixed

::: netwerk/cache2/OldWrappers.cpp
@@ +217,5 @@
> +  nsRefPtr<_OldGetDiskConsumption> cb = new _OldGetDiskConsumption(aCallback);
> +  rv = serv->VisitEntries(cb);
> +  NS_ENSURE_SUCCESS(rv, rv);
> +
> +  // Expected to be redispatched.

The comment should explain why it has to be redispatched. Btw. by redispatching (without further specification) I understand that the event will be dispatched to the current thread. So please fix either the code or the comment.
Attachment #8409362 - Flags: review?(michal.novotny) → review+
Attached patch v1.1 [to land]Splinter Review
- comment updated
Attachment #8409362 - Attachment is obsolete: true
Attachment #8410958 - Flags: review+
Note: the true cause was a bug in _OldVisitCallbackWrapper that didn't count on fact a device may not be active - it has never called the onCacheStorageInfo callback for the disk device. See https://bugzilla.mozilla.org/show_bug.cgi?id=916052#c21
https://hg.mozilla.org/mozilla-central/rev/6cea265963a6
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Dao, are you able to reproduce this in the latest beta?
Flags: needinfo?(dao)
clearing old needinfo request that probably isn't relevant anymore
Flags: needinfo?(dao)
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.