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.

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.

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

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)

Just disabling the buttons after the action has been completed would make the user understand the it has been done, correct?

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!

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

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

Suresh, can you take a look at this to see what we should do about it?

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

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?

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

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

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

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.

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