Closed Bug 115499 Opened 21 years ago Closed 16 years ago

Remove the warning dialog before automatically compacting folders


(MailNews Core :: Backend, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: jonasj, Unassigned)



(Whiteboard: [adt3])

When it's time to compact folders, why ask if I really want to do it? If I
didn't want folders to be compacted automatically, I would have turned it off in
Keywords: 4xp
reassigning to naving.  
Assignee: sspitzer → naving
Target Milestone: --- → mozilla1.2
QA Contact: esther → sheelar
Hmm, I'm not seeing a "Do you really want to compact folders?" dialog.
No, we want to inform the user that we are going to compact the folders, so
that he is aware what is going on. It might seem a bit awkward, if he sees
thread-pane refresh. 

But can't it at least be a pref? Advanced users can understand what's going on.
They don't want to waste time pressing OK in some dialog. At least I don't.
See bugs 114298, bug 114210 regarding compact folder dialog issue. People don't
like the idea of the dlg coming up as soon as they log-in which is what we do.  
If you set your preference|offline & Disk space-" Compact folders when it will
save over {n} kb.  Check this pref with a low number. Delete or move a message
account that exceeds the threshold limit.  Exit and restart you should be able
to see the dialog at start up.   
Sorry the correct bug is 114302 not 114298.  
*** Bug 123132 has been marked as a duplicate of this bug. ***
This dialog does seem to be pointless and annoying. Why not just automatically
compact and say "Compacting folders..." with % complete in the progress bar?

I bet that's what most people expect the behaviour of the pref to be anyway.
In my point of view, the "compact folder" option in the prefs should be
activated by default. This is a point that ALWAYS annoyed me with netscape 4.x
> In my point of view, the "compact folder" option in the prefs should be
> activated by default.

I agree, but this is completely off-topic to this bug. Please file it as a
separate bug.
nominating this bug for the next release.  
Keywords: nsbeta1
Blocks: 116215
*** Bug 173200 has been marked as a duplicate of this bug. ***
As with other dialogs of this kind I suggest adding a check box to it with "[ ]
Don't show this warning again" and store it in a user pref.

This bug is *extremely* annoying when heavily moving mail between different folders.
The question is meaningless to the users so why have a checkbox that controls
the behaviour? If it has to be a pref (again why?), then a hidden one should
QA Contact: sheelar → esther
> The question is meaningless to the users so why have a checkbox that
> controls the behaviour? 

I do not object to get rid of this message box entirely.

> If it has to be a pref (again why?),

If we can remove the box, we won't need a pref, of course.

> then a hidden one should suffice.

Mail triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
*** Bug 189989 has been marked as a duplicate of this bug. ***
Behaviour of the compacting needs to be controllable as I explained in my
original  feature request (bug 189989).

Both time done (program startup, after new mail received, program shutdown, all
of the above) and the automation as discussed here need to be finely controllable.
re-assigning nsbeta1+ bugs
Assignee: naving → sspitzer
Target Milestone: mozilla1.2alpha → ---
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3.1) Gecko/20030425

I agree that the dialog is annoying, but there's a wrinkle: when I start up
mail, all my pop accounts retrieve mail--if I let Moz compact folders at the
same time, I get an error message about folders in use, check mail later,
blabla; so this dialog actually gives me a chance to hit the little "unplug"
(offline) doodad before I click OK and let it compact away.

This may be a separate issue, but I think if the dialog is removed, the
automatic compacting of folders should also (a) suspend or delay mail retrieval;
and (b) temporarily go into offline mode (if not already in offline mode).
*** Bug 233961 has been marked as a duplicate of this bug. ***
My apologies for filing a dup, I obviously didn't search hard enough - But, can
I ask why nothing has been done since 2001? Is it complicated to fix or is there
no agreement about what should be done? The present dialog is both pointless and

Does anyone know how thunderbird behaves in this situation? I'm pretty sure I
haven't seen this in TB, in fact I can't even seem to find the folder compacting
prefs in TB...
*** Bug 248661 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: sspitzer → mail
*** Bug 324217 has been marked as a duplicate of this bug. ***
interesting behaviour on TB 1.5 : 

configured : "empty trash on exit" per account. 
configured : "compact folders if save more then 100KB" in advanced prefs. 

deleted >200KB worth of messages from inbox. 

exit TB. nothing happens. (apparently)

start TB again. Now I get the annoying dialog "do you whish to compact folders" ... 

When is this compact folders command issued ? on startup? 
I strongly agree with all of comment #21 except the last paragraph.  TB should never interrupt the process of getting new messages to perform automatic compaction; rather, it should disable automatic compaction until it has finished getting all the new messages.  (Or at least, the user should be able to set TB to work that way.)
When the dialog gets a "Do this automatically from now on" checkbox (bug 198936), it no longer needs to be removed.
Depends on: 198936
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
The checkbox patch was just checked in. I think it's now safe to assume that the dialog will not simply be removed - more information about why it is useful can be found in bug 198936 comment 9. Further enhancements, especially timing improvements, should be discussed in bug 321641.
Closed: 16 years ago
Resolution: --- → WONTFIX
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.