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

RESOLVED FIXED

Status

()

Firefox
Preferences
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: stevee, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({regression})

Trunk
x86
Windows 2000
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

13 years ago

*** This bug has been marked as a duplicate of 66012 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Comment 2

13 years ago
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.
Flags: blocking-aviary1.1?

Comment 3

13 years ago
(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.
kwd regression
->reopened
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: DUPLICATE → ---

Updated

13 years ago
Severity: trivial → normal
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. 
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED
(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.
(Reporter)

Comment 7

13 years ago
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?
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.
cant it just use the same code as prefwindow iv?
No, because then you always have to close and reopen the prefwindow to clear
cache again.

Comment 11

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

13 years ago
(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?
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.
Flags: blocking-aviary1.1?
(Reporter)

Comment 14

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

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

Comment 16

13 years ago
nope...
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.