283601 - Privacy > Cache > "Clear Cache Now" not greyed out after clicking

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Steve England [:stevee]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050225 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050225 Firefox/1.0+

After clicking on "Clear Cache Now" in Tools > Options > Privacy > Cache > the
button is not greyed out. In other option tabs (Download History, Saved Forms,
etc) the "Clear <name> Now" button always greys out afterwards to indicate the
whatever is totally empty and cleaned.

Reproducible: Always

Steps to Reproduce:
1.Go Tools > Options > Privacy > Cache > and click "Clear Cache Now"

Actual Results:  
button remains clickable after cache clear

Expected Results:  
button becomes greyed out and unclickable to indicate cache has been cleared and
there's no point in clicking it again because it's already empty.

Comment 1

[Jo Hermans]

*** This bug has been marked as a duplicate of 66012 ***

Comment 2

[u88484]

I think this bug should not be duped to 66012. This bug was caused after the new
options dialog was checked it and deals with the deal options dialog.

Comment 3

[Jo Hermans]

(In reply to comment #2)
> I think this bug should not be duped to 66012. This bug was caused after the new
> options dialog was checked it and deals with the deal options dialog.

Bug 66012 isn't Firefox-specific. And the problem existed before too.

Feel free to reopen the bug ofcourse.

Comment 4

[Peter van der Woude [:Peter6]]

kwd regression
->reopened

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

I've made the button re-enable on a 10s timer... there is no way to tell if the
cache is empty or not, at least not that I know of, so we have to reenable it
later anyway to allow the user to click the button again if they browse in
another window and populate the cache again. 

Comment 6

[Grayson Mixon (ColdFusion650)]

(In reply to comment #5)
> I've made the button re-enable on a 10s timer... there is no way to tell if the
> cache is empty or not, at least not that I know of, so we have to reenable it
> later anyway to allow the user to click the button again if they browse in
> another window and populate the cache again. 

if theres no way to determine if the cache is empty or not, why does it gray out
on prefs iv? there, if its empty it grays out. if its not, u can click it. just
copy whatever the old mechanism is.

Comment 7

[Steve England [:stevee]]

Since the prefs window is modal, can you not simply grey the button out on
click, and only re-enable it after the user has closed the prefs window and
re-opened it?

Comment 8

[Mike Connor [:mconnor]]

Its only modal on Windows, and its only modal for the current window.  Other
windows can continue to browse and write to cache anyway.

And it disabled on prefwindow IV because the code disabled it deliberately.

Comment 9

[Grayson Mixon (ColdFusion650)]

cant it just use the same code as prefwindow iv?

Comment 10

[Mike Connor [:mconnor]]

No, because then you always have to close and reopen the prefwindow to clear
cache again.

Comment 11

[Kai de Leeuw]

Can't one use the same code that is used to display the page "about:cache"? It
shows the exact number of entries, so it should indeed be possible to find out
if the cache is empty or not. 

I don't know much about the mozilla codebase, so maybe I am just making a stupid
suggestion here. But setting a 10 sec timer feels like a very unelegant and
hackish way of solving the problem.

Comment 12

[Worcester12345]

(In reply to comment #11)
> Can't one use the same code that is used to display the page "about:cache"? It
> shows the exact number of entries, so it should indeed be possible to find out
> if the cache is empty or not. 
> 
> I don't know much about the mozilla codebase, so maybe I am just making a stupid
> suggestion here. But setting a 10 sec timer feels like a very unelegant and
> hackish way of solving the problem.

I was going to go "unvote" for this bug, but don't want to until I see an answer
to this question. Anybody?

Comment 13

[Mike Connor [:mconnor]]

Please file a followup on that, but its not a critical issue, and I'm not sure
what kind of overhead is associated with that.  If there's a cheap way of
checking cache, fine, but anything that's going to repeat on a timer has to be
very efficient.

Comment 14

[Steve England [:stevee]]

IMO it's an acceptable fix. It gives the user feedback that the cache has been
cleared and makes the button work like the other 'clear' buttons (eg: clear
cookies). I guess when the cache code gets reworked this issue could be looked
into some more, but for the time being I think it is an acceptable approach.

Comment 15

[Worcester12345]

Kai de Leeuw: Did you ever do the "followup on that"? Thanks.

Comment 16

[Kai de Leeuw]

nope...

Comment 17

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change