Closed Bug 66012 Opened 24 years ago Closed 14 years ago

User Preference - Clear memory and Disk cache - no indicator shown

Categories

(SeaMonkey :: Preferences, enhancement, P4)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED
Milestone:
Future

People

(Reporter: jmac, Assigned: skasinathan)

References

Details

(Whiteboard: [cache]) 

When the clear cache buttons are pressed, I see no indication, either from a pop 
up box or task bar notation that these actions were completed??
The guaranteed way of knowing would be to trash these cache folders from the 
user profile via the hard drive.
I see this also, but I'd bet there is a reason for this to be the case. 

Confirming, but I bet this gets marked WONTFIX later.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can live with this nuisance,- another one of those insects to look into after 
the major stuff is dealt with; Like Memory useage and rendering speed.

over to cache.
Assignee: asa → neeti
Component: Browser-General → Networking: Cache
QA Contact: doronr → gordon
There should be a warning dialog that pops up, asking the user if they're sure 
they want to empty the cache(s) (as in Communicator). The progress is indicated 
by the inactive button - if you click the "Empty Cache" button, it becomes 
"greyed out" until the action is complete. But there should still be a warning 
prior to deleting the cache.

Are you sure this belongs in networking? It seems to be strictly a prefs issue.

Cache bugs to Gordon
Assignee: neeti → gordon
Target Milestone: --- → mozilla1.0
Depends on: 63539
Component: Networking: Cache → Preferences
Whiteboard: [cache]
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Just disabling the buttons after the action has been completed would make the
user understand the it has been done, correct?
OS: Mac System 9.x → All
Hardware: Macintosh → All
Summary: User Preference - Clear memory and Disk cache - no ndicator shown. → User Preference - Clear memory and Disk cache - no indicator shown
They now grey out. Don't know when or why or where, but location bar greyed out
and remained grey when I went back to prefs. Oddly, it had adverse affects on my
personal toolbar (it gets taller onMouseOver). Should we mark this FIXED?
I take that back, location history greys out, browsing history, the first 3
times I clicked it, did nothing. I opened up history manager, and everything was
still there. Then, with that open, I clicked it again, and it churned for 73
seconds, then all my history was gone, but they button wasn't greyed. Still an
issue. Filing bugs on the other things I encountered.
it has absolutely no effect when clearing memory or disk cache in user
preferences. In addition (at least) disk cache is not limited by the value you
put in here!
Depends on: 142970
No longer depends on: 142970
*** Bug 142970 has been marked as a duplicate of this bug. ***
*** Bug 142970 has been marked as a duplicate of this bug. ***
*** Bug 154217 has been marked as a duplicate of this bug. ***
Severity: normal → enhancement
Component: Preferences → Networking: Cache
QA Contact: gordon → tever
I think the interactive "Clear Disk Cache" function should definitely have some
kind of user feedback while the operation is in progress. Caching can take a
long time (possibly multiple minutes?), and it is not obvious that the
application is still functioning during this time (it appears "hung" to the
impatient amongst us). On Windows (where I am running), the typical thing to do
in these cases is to diplay the hourglass cursor or a progress bar during a
lengthy operation.

Greying buttons at the end would confirm completion, but not progress. I think
we need both here.

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.
*** Bug 170665 has been marked as a duplicate of this bug. ***
Priority: -- → P1
Suresh, can you take a look at this to see what we should do about it?
Assignee: gordon → suresh
This has gotten much worse since bug 103851 was fixed (clearing the cache is a
seperate thread). It will now happen in the background, so you really don't know
if something happened or not. There's no grey button anymore, because the action
(starting the thread) is immediately finished.
I'm trying to start coding for Mozilla and as a first test i'm looking at this :
the greying out of the Clear Cache button.

Would the code for that look something like [and sorry for the formatting, i
don't have my own computer handy for making a proper CVS patch]

in /xpfe/components/prefwindow/resources/content/pref-cache.xul

line 68
old
oncommand="prefClearDiskAndMemCache();"

new
oncommand="prefClearDiskAndMemCache(); this.disabled = true;"

retargeting
Target Milestone: mozilla1.0.1 → Future
What's with this bug? There's a solution in additional comment #19 from Patrick
Hendriks. Why the solution was not included till now (checked release 1.7rc2 as
latest)? This bug is dependent on bug 63539 which has been, however, fixed. 
->p4

Michael:
this snippet is pretty far from being a usuable change to the tree: This bug
needs an assigned owner, a patch, and a target milestone.

How often are inexperienced users clearing cache? What is going wrong when they
don't get feedback? How important is this vs. the other cache bugs?
Priority: P1 → P4
QA Contact: tever → benc
*** Bug 283601 has been marked as a duplicate of this bug. ***
Component: Networking: Cache → Preferences
Product: Core → Mozilla Application Suite
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
Bug confirmed on Seamonkey 2.0.4 and Firefox 3.6.3 win32.

Go to preferences, where the cache settings are and "clear now" button. 

Press the button. Apparently nothing happens. IMHO, the button should become inactive to show that the cache has been cleared.
Ever confirmed: true

    
    

    
  
(In reply to comment #31)
> Bug confirmed on Seamonkey 2.0.4 and Firefox 3.6.3 win32.
> 
> Go to preferences, where the cache settings are and "clear now" button. 
> 
> Press the button. Apparently nothing happens. IMHO, the button should become
> inactive to show that the cache has been cleared.

Agreed that there should be some feedback that something happened, and there is not, so this bug should be reopened.

          You need to log in
          before you can comment on or make changes to this bug.