101584 - Improve alert for compact folder interruption by biff/auto get msgs. Currently "This folder is being processed. Please wait until processing is complete to get messages."

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[laurel]

Using sep25 commercial 0.9.4 branch

If you're compacting local folders and the process is interrupted by getting new
messages, an alert displays: "This folder is being processed. Please wait until
processing is complete to get messages." 

Said alert displays whether the user did a manual Get Msg while compacting was
in progress or whether an automatic process such as biff/auto-download did the
interrupting.

In the case where the user manually activated getting messages, this alert
should be fairly clear to the user.

In the case where an automatic setting/process causes the interruption, I'm not
sure where this alert will be clear or if it might cause confusion to the user
(since they might not focus on say, biff, being the cause).

I'm logging this bug to address/evaluate the alert in the auto-interrupt cases.

Comment 1

[laurel]

For reference: This was noticed while testing bug 95584.

Comment 2

[Navin Gupta]

I have already logged bug to add more error diagnostics for compact - bug 101057.
Unfortunately, you cannot distinguish between automatic downloading on biff 
and user pressing GetMsg(). I am inclined to mark this bug won't fix.

Comment 3

[Navin Gupta]

But you could say in the error dialog that this could have happened either 
due to biff or due to GetMsg() triggered by the user. Please suggest an 
appropriate wording. 

Comment 4

[jglick]

How about just not allowing "Get Msgs" while a compact operation is in progress?
4.x has a modal dialog that is displayed (indicating the progress) while the 
compact is in progress.

Comment 5

[robinf]

I agree with Jennifer that it would be better to prevent this error from
happening in the first place. Otherwise, suggested wording for the alert in the
auto-interrupt case could be: "Local and offline folders could not be compacted
because another operation was in progress. Please try again."

Comment 6

[timeless]

Please try again _later_.

but of course avoiding the problem is a better idea :-)

Comment 7

[Navin Gupta]

4x has a modal progress; we do not have that here, i think informing the user 
that messages cannot be downloaded because compact is in progress is sufficient.
robin, you have suggested wording for another scenario. 
My suggessted wording : "The message cannot be downloaded because another 
operation is in progress. Please try again later."

Comment 8

[jglick]

Good software shouldn't allow users access to things that we know for sure are 
going to fail. And then we add insult to injury by displaying a dialog that 
tells them they can't do this after the fact. 

At a minimum, maybe make the "Get Msg" button/menu item disabled and show status 
of the compact action in the status bar. Making a compact progress modal dialog 
would be a better solution though. 

Comment 9

[scottputterman]

I think the best solution is what Jennifer wrote.  Disable Get Msg and prevent
biff from happening during the compact folder operation.  Adding a dialog or
better status is an even better improvement, but we should allow operations that
we know are going to fail.

Comment 10

[laurel]

still exists dec14 commercial trunk

Comment 11

[Matthew T (active 1999-2002)]

Simply disabling items which can't be used right now is often a good approach,
but not always; sometimes it is not at all obvious *why* an item is disabled, so
it is marginally better to enable it and put up an alert explaining why it can't
be used.

Luckily, in this situation there is a solution which avoids either the alert
*or* the disabling: do what 4.x did. That is, put up a progress window as normal
for getting messages (preferably not following 4.x's habit of putting this
progress window in exactly the same place as the one which is already open),
with the text `Waiting for access to folder "NameOfFolder" ...'. Then queue the
message fetching until the compacting has finished.

Comment 12

[Rainer Bielefeld]

I see the Problem in a different way, bugfixes still are needed. 
Results with all Versions starting with 0.9.7 similar to
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:0.9.9+) Gecko/20020319

When I want to get Messages from POP3-Server I often see as following 
!! means unexpected :_wrong_ reaction
=> means reaction as expected
-- means reaction

1. I select "Mail & news"
   => mail and news module opens, my account is selected
2. mouseclick "read messages"
   -- message "do oyu wish to compact all local folders to save disk space"
3. mouseclick "yes"
   !! invitation to enter Pasword
   => status-bar-message: "compact folders" but 
   !! compacting folders is _blocked_ by invitation to enter password
4. I enter Password / mouseclick "OK"
   !! Alert "This Folder is being Processed. Please wait until processing is 
      complete to get message"
   !! status-bar-msg: "Host connected, sendign login information" 
5. I enter "OK" for alert
   => mozilla starts to compact folders
   !! status-bar-msg.: "Connect: Host connected, sendign login information"
      That is _wrong_, status bar should show which folder actually is being
      processed (as in NC4.7)
6. mozilla finished compacting folders
   !! status-bar-msg.: document done
      msg. should be "folders compacted" or similar
7. now I can try again to read messages fom POP3

I Think:
- messages in status-bar shoule be corrected
- mozilla should hadle a "batch" automatically: first folders will be compacted, 
  and after this mozilla fetches the messages from the POP3-server automatically   
  without new user-activity for second password-enter etc.


Keywords should be entered:
mail1 

 
  

Comment 13

[Sheela Ravindran]

Nominating this bug for the next release because many have expressed they rather 
have the get message disabled during the compact process. This bug should be 
considered for better user experience.

Comment 14

[Sheela Ravindran]

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

Comment 15

[Sheela Ravindran]

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

Comment 16

[David A. Cobb]

In a related situation, if a (local) folder is being compacted the filtering is
unable to deposit a message there.  It appears to be dropped into Inbox.

In *both* cases, it would be most appropriate to queue the messages in a
temporary mbx (another "nstmp") and process them through the incomming-message
and filtering logic after the block has been cleared.

As to user experience, probably many of us set our POP account to poll and
automatically download.  We don't know in advance when this will happen, so it
is a very rough edge to our experience when some part of the system fails
because another part is busy.

Comment 17

[Troodon]

I'm using 20020918 and Win98 SE. I "suffer" the two problems described about
(the error message when automatically getting mail while compacting folders and
the filtering not working while compacting). I think the best solution would be
to perform only one operation (compacting or getting the mail) at a time.

Comment 18

[David A. Cobb]

Re: Comment#17:  Ironically, it could be very easy.  At the start of the
program, the "Do you want to compact ..." dialog is MODAL -- nothing at all
happens until you deal with it.  If you're not sitting at the machine, there
could be enough time to collect the mail before you even answer; but that's in
the opposite direction.

If the entire COMPACT process were made MODAL, this bug would go away.  If the
program is doing a compaction the odds are that anything else it attempts will
cause a conflict  -- so don't try anything else.

Personally, however, I would much prefer never to see the "Do you want to
compact . .." at the startup.  I liked the old NS behavior of compacting at
shutdown much better.

Comment 19

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 20

[Serge Gautherie (:sgautherie)]

Please, see bug 188728 comment 4;
especially for updating the summary of bug 101584 also.

Comment 21

[R.K.Aa.]

bug 188728 almost looks like a duplicate of this. Was the wording on the alert
changed?

Comment 22

[Serge Gautherie (:sgautherie)]

Attachment: Screen capture (16c) of the message, from Moz v1.4a

(Compact Folders was running when Get New Messages started.)

Comment 23

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

Re comment 21:

The alert wording remains unchanged untill now:
"This folder is being processed. Please wait until processing is complete to get
messages."
(cf attachment 121328 [details], from comment 22)

PS: I updated bug 188728 summary; and I support the idea that theses 2 bugs
should be made duplicates, but I don't feel qualified to take this decision.

Comment 24

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 25

[volps]

Re: Comment#18: Personally, however, I would much prefer never to see the "Do
you want to compact . .." at the startup. 

This makes sense, in my user way of thinking. When Mail starts, I want to get
new messages, NOT to compact folders. It's better to show the modal dialog about
compacting AFTER the first attempt to automatically get new messages. It's
annoyning the way it is done in 1.4.

Comment 26

[David A. Cobb]

Personally, I liked the way Mozilla did it Waaaayyyy Back -- an option when you
exit mail or otherwise are finished with the folder.  If I'm shutting down for
the night I can say now and I'll soon be able to shut down; otherwise the
compaction becomes a more-or-less background operation while I've gone on to
other things.

Doing this during startup, when the folder is almost guaranteed to be busy, is
like the worst possible choice!

Comment 27

[Jon Baumgartner]

(In reply to comment #25)
> Re: Comment#18: Personally, however, I would much prefer never to see the "Do
> you want to compact . .." at the startup. 

I would love an option to never see those messages again. I want it to compact,
but I don't need to confirm it every time.

Comment 28

[Vincent Deconinck]

I also see this bug for years about twice every week, and I know I have to 
answer "No" the "Auto-compact" confirmation on Mail startup to get my mail.
However, today, I unluckily discovered that pressing Yes and letting auto-
compact and auto-download fight for the Inbox can sometimes lead to data loss.
In my case, 400+ yet-to-be-answered e-mails just got lost forever, because of 
the conflict. Asking DATALOSS keyword to be added.
Does anyone have a hint about where a "temporary Inbox" is created during the 
compact process ? Maybe I can try and undelete it...

Comment 29

[David A. Cobb]

Re: Comment#27

In the dim days of Netscape Navigator, IIRC, compression was offered upon
quitting the program or when "leaving" a particular mailbox.  I'm not all that
fond of anything to make quitting worse -- that's another issue anyway -- but
one can also say "no" without serious consequences.

If "leaving" is insufficiently clear, suppose I have only a single three-pane
window with "Inbox" highlighted.  When I then select a different mailbox to view
I have "left" Inbox -- it need not remain open and it could be silently
compressed in the background without anoying anyone.

Comment 30

[Brad K.]

Whatever is done about conflict of compress folders and checking incoming mail
needs to work at startup.  Presently (1.8a2) I get the option of clicking 'no'
on startup (seems a worthless wastes), or click 'yes' to confirm compressing
folders -- followed by a dialog explaining compress failed because the folder is
busy (downloading SPAM).

1) On startup *never* blink anything on the screeen or window.
2) On startup queue 'compress folders' when enabled after completion of check
messages (for automatically checked accounts) plus a user-settable delay (to
allow manually checking accounts; default to 20 seconds[?]) before lauching --
with no dialog, maybe a status bar message that compress folders has started,
and again when completed.
3) In today's SPAM environment the only menu settings I hit more often than the
'junk' and 'delete' buttons -- are the 'empty trash' and 'compress folders' menu
items.  This seems a wasteful and irritating flaw in the interface.  Perhaps a
preference to compress (without confirming dialog) when leaving the account
(queued after any existing 'check messages' states).
4) The 'empty trash' and 'compress folders' menu items are confusing in their
scope.  Being placed in the 'Files' menu, I would expect them to be global, and
one click should empty/compress all accounts.  Please change these items to
'empty current trash', and 'compress current account folders', and add 'empty
all trash' and 'compress all account folders'.  
5) Along with #4, add an optional button with sticky state, to select empty
trash on either the current account or all accounts simultaneously, with an
option to also (silently) compress the current/all account folders.

And again, *please* disable the flashing title bars and system buttons when
starting up and compress wants to fire but there will be incoming messages for
the next 3 minutes (dialup is slow!).  This is very irritating.

Comment 31

[Jens Bannmann]

Moving to Core, as this code is shared between Thunderbird and SeaMonkey.

For the record, bug 198936 introduced a checkbox to suppress the folder compression confirmation message. The other issues remain, however.

Note: Several other bugs about this topic are mentioned in the aforementioned bug, might be worth reading.

Comment 32

[David :Bienvenu]

not a database issue...also, we don't offer to compress folders on startup anymore, but rather, after you delete a message that puts you over the limit...

Comment 33

[Tony Mechelynck [:tonymec]]

No action in more than a year, not blocked by another bug.
Comment #32 seems to imply WONTFIX but I'm not sure.

Comment 34

[Wayne Mery (:wsmwk)]

Mark, David, wontfix?  (comment 32)
or perhaps blocked by bug 286888 given 286888 should seek to avoid/eliminate the problems cited in this bug.

Comment 36

[Vako]

Any update of this 11 year-old bug?  Still happens several times daily on my computer. There are 3 bug reports opened for it, both for Windows and MAC and yet no solution.  I am using TB 10.02
Since it's just information and the only option is an OK, why display it?  at least give us an option to "don't display again".
Thanks!

Comment 37

[Wayne Mery (:wsmwk)]

(In reply to Vako from comment #36)
> Any update of this 11 year-old bug?  Still happens several times daily on my
> computer. There are 3 bug reports opened for it, both for Windows and MAC
> and yet no solution.  I am using TB 10.02
> Since it's just information and the only option is an OK, why display it? 
> at least give us an option to "don't display again".
> Thanks!

Vako, is this pop type accounts? and are you using global inbox?

Comment 38

[Vako]

> Vako, is this pop type accounts? and are you using global inbox?

Yes they are pop-up dialog boxes and I am using Global Inbox.
Seems it happens only if you have multiple accounts and if one is taking too long to download messages the other account kicks-in and prompts for that dialog.

Comment 39

[Vako]

Is it really fixed? --> https://bugzilla.mozilla.org/show_bug.cgi?id=592235#c54

Comment 40

[:Hb]

(In reply to Vako from comment #39)
> Is it really fixed? -->

Yes, the alert has been FIXED the blocking folders name is now shown. 

Other internal issues with blocked folders mentioned in:
> comment #0
> ... In the case where an automatic setting/process causes the interruption, ...

> comment #8
> ... At a minimum, maybe make the "Get Msg" button/menu item disabled and show
> status  of the compact action in the status bar. ...

are open in other bugs:

Bug 498274 - [Meta] Issues around simultaneous "view mail, delete/append of mail, update of mail data, read by other" and "compact folder" of local mail folder and IMAP offline-store 

Bug 188728 'Compact Folders / C. f. when it will save over nn KB' and 'Get New Messages / Automatically download new messages' should never block one another