Open Bug 247193 Opened 21 years ago Updated 6 months ago

imap quota notification is displayed again and again

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect

Tracking

(Not tracked)

People

(Reporter: prohaska, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.2 (KHTML, like Gecko) Safari/125.8
Build Identifier: version 0.7

if a imap server thunderbird is connected to sends notification messages, e.g. 'Mailbox is at 85% quota' 
thunderbird displays this message using a requester. This is done again and again after every change of 
the mailbox or other actions. 
E.g. selecting 'File -> Compact Folders' triggers a display of the requester for every visited mailbox. 
This behaviour makes Thunderbird very annoying to use (in my opinion unusable) in case of imap 
server messages.
Instead of displaying the message again and again a better notfication method should be used. Apple's 
Mail e.g. displays a small icon at the account indicating that the server wants to notify the user. Only 
when selecting it the real message is displayed *once*.

Reproducible: Always
Steps to Reproduce:
1. Connect to a imap server with quotas and notification enabled. 
2. Use enough storage to trigger the server notification.
3. Change mailbox/select 'File -> Compact Folders'
Actual Results:  
A warning requester will be displayed again and again.

Expected Results:  
Display a warning once per session or use another mechanism to indicate a imap server message.
Having the same problem. Doing a File->Compact Folder causes Thunderbird to
display the quota warning several times in a row (i.e. when I click "okay" or
hit return, it displays the message again immediately). (As per "several," the
number seems to vary; so far I have seen as few as I think 4 and as many as 7).

Found on version 0.7.1 on OS X 10.3 and on the 0.8 nightly build for July 20.
*** Bug 261940 has been marked as a duplicate of this bug. ***
*** Bug 264015 has been marked as a duplicate of this bug. ***
Having the same problem.  What appears to be happening (from an IMAP trace) is
that the compact folders operation goes thru each folder in the mailbox doing a
compact (as it should).  What is incorrect is that it is also doing a quota
check and displaying that basically for every folder!... If you have lots of
folders, beware!

This is a platform independent bug as the same thing happens on the Windows release.
I also have major grief with this. Using Mozilla (or Thunderbird) to access a
mailbox residing on a Cyrus IMAP server with quota enabled can cause user
problems. Cyrus has a quota, and a warning threshold, which is set by default to
85% of the total quota. So, if a user has a 100Mb quota, when they reach > 85Mb
of mail, Cyrus will start sending quota warnings. It does this by using the IMAP
ALERT keyword, and pretty much every IMAP operation by that user gets an IMAP
ALERT tagged onto the protocol exchange.

All this is OK until the user takes an action that results in a number of IMAP
protocol operations. To give a specific example if Mozilla polls all folders
(admittedly this example is slightly outdated with IDLE support, but there are
others), an ALERT gets generated for every folder on the system. If a user has
50 folders (not uncommon), Mozilla then sequentially generates 50 *modal* dialog
boxes that the user is forced to dismiss before the application is usable again. 

If subsequently, the user selects a block of emails, and deletes them, Mozilla
moves them to the Trash. Each COPY operation to the trash folder produces
another modal dialog. The user can be forced to dismiss literally hundreds of
such dialogs before the application returns to usability, even when they never
reached the actual quota limit. Typically I get a phone call from a distressed
user before they reach this stage.

I have resorted to setting separate quotas on Trash folders, which alleviates,
but does not solve the problem. Using shift-delete can also help a little, but
the fundamental issue remains. Could mozilla not be made to display information
provided by the server via IMAP ALERT in a notification area in the status bar,
in a manner that does *not* require the user to click to dismiss the
notification? Quota messages in particular could be captured and just displayed
in a subtle fuel-gauge type manner. Rendering the entire application
unresponsive behind a stack of modal dialog boxes seems to me to be the worst of
all worlds. I'm sure most home users will never see this, but it's a very
serious usability problem if you're trying to run a network with
Thunderbird/Mozilla mail - I'm sure whoever wrote the current behaviour wasn't
using a mailbox with a quota.


I heard today that a RC is available. Someone should definitely consider dealing with this bug. It makes 
Thunderbird *unusable* with an IMAP server when hitting quotas. I'd propose to schedule this bug for 
1.0 as a blocker.

As Peter Lei commented, this bug is platform independent.
OS: MacOS X → All
Hardware: Macintosh → All
I would also *very* much like to see this bug fixed before Thunderbird 1.0
releases, and agree that it should be considered as a blocker. It seriously
impacts on the user experience of what is otherwise an excellent product. While
the affected userbase may be a minority at this point, quota use is pretty much
mandatory in any business environment, so this is only going to affect more
people as Thunderbird's userbase grows.
Sounds serious. Several sensible reports. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Similar problem if the server is unavailable.

I'd lost the network link to the server and inadvertently selected "compact
folders" only to have to dismiss multipe "server unavailable" dialogs.
Holy ****. This bug is _still here_. So annoying.
See also Core bug 242396.
This makes thunderbird highly annoying to use when one is getting close to limits. Any chance it could be fixed for thunderbird 2?

I get the notification for each folder I select. Normal folders seem to not redisplay it for a while (the current session?), but special folders like Drafts/Templates/Trash etc. display the dialog for each an every select.
Flags: blocking-thunderbird2?
doesn't look like we've gotten any traction on this yet. Would take a patch if we  got one.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Keywords: helpwanted
QA Contact: front-end
So, I've been suffering from this for a number of months.  The big problem is that I use Thunderbird to filter mail for me, and when the dialog is open, it stops filtering (in addition to the UI issues).  My hack is to prevent the alert from popping up when it matches the Quota Alert pattern (approximately):

I changed the "if" statement in nsImapProtocol::AlertUserEvent(const char * message) -- in the file .../mailnews/imap/src/nsImapProtocol.cpp
from:
if (m_imapServerSink)
to:
if (m_imapServerSink && ( (strstr(message, "Mailbox is at") == NULL) || (strstr(message, "% of quota") == NULL) ))

That's good enough for me :o)
Not good enough for me, though!  What about TB updates?  What about those of us unable to compile our our version of TB?  It's a nice hack for those who don't mind maintaining their own personal branch of TB, but for the rest of us...

any chance of integrating omari's code in the configuration somewhere, TB team?  

thanks,
allie
(In reply to comment #16)
> any chance of integrating omari's code in the configuration somewhere, TB team? 
See http://developer.mozilla.org/en/docs/Developing_Mozilla, especially http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree
.

There is also the minor problem I foresee that his patch doesn't appear to handle i18n issues, by hardcoding such information. But hey, I'm not the reviewer, so my voice doesn't count.
The other issue is that the text of this message comes from the server (see
log output in bug 242396 comment #2), thus depends on what you are connecting to. At least with the TB default theme, such a quota message also is redundant as a quota meter appears in the status bar when the quota usage specified in "mail.quota.mainwindow_threshold.show" is exceeded. If you have access to the IMAP server, it may be a configuration option to omit quota notifications to the client as a workaround.

This problem is similar to bug 123440 on repeated messages popping up for connection failures. In general, modal dialogs reiterating the same problem over and over are not helpful and an annoyance in the end. One possibility would be to keep track of messages as they come in, show the first instance, but then suppress any follow-up messages. A problem being, assuming you get a warning of 91% quota used, should a following message with 92% usage be shown (as it is not identical to the first instance) or hidden (since it is similar enough to the first one). It may be tricky to develop such a logic.

Other potential options are to follow the proposal in bug 244491, globally replacing such modal dialogs with an alert window collecting a history of messages without disrupting the normal workflow; or bug 123440 comment #24, color-coding accounts or folders with problems (being it a lost connection or approaching the quota).
Yeah, the change I made was meant as a hack, rather than as an actual fix.  I'm of the opinion that Mozilla products (specifically, I use firefox and thunderbird regularly) use modal dialogs needlessly in many contexts in the first place.  So that means that there are two problems here: (1) how to display this information in a way that's useful and prominent (if necessary), but that is not an annoyance or hindrance, and (2) how to deal with possibly-very-redundant messages of various sorts from servers.

Clearly, a nice solution to (1) should be able to easily compress redundant messages, and consequently, deal with (2) inherently.  For instance, as another cheap hack, just having a _single_ dialog that says how many identical messages it represents would be better than what currently happens (of course, you'd likely get to do something with singleton classes so you could keep that state).

The next logical step is to combine these separate dialogs into a single, stateful dialog (much like rsx11m mentioned).  I'm thinking of something that could, for instance, group messages by identity, and communicate (if requested), for each group, how many messages are in that group and when they each arrived.  Thus, it would useful (it maintains all of the information that server sent) and it could be made prominent (flash something, or stick a "!" sign in the status bar).  However, it could be easily dismissed, and (likely) could be configurable to not become prominent again if messages arrive that are identical to those it's already shown.

Put this way, though, it's clear that the functionality I'm trying to describe is simply a tailored log viewer.  That shouldn't be that hard (spoken with a large dose of naivete)

As for rsx11m's question about 91% vs. 92%, I think you could just handle it with 3 cases: (1) show all quota messages, (2) show unique quota messages, (3) suppress all quota messages.
The simple fix would be to just store the message shown in an in-memory variable. If the server sends a message, check against this var, and if the message matches exactly, don't show it, as we have already shown it. Given that it's only stored in RAM, the message will be shown again the next time Thunderbird is started, which is probably desirable.

I agree that there are much nicer solutions without modal dialogs. The same mechanism is used and problem appears when Thunderbird can't connect to the server. The implementation of FEAlert in nsImapIncomingServer.cpp would need to be changed, to e.g. show an infobar (like Firefox does) in the main mail window for that account only. All that would be a different bug, though.
Is there a way to do that while keeping nsImapProtocol::AlertUserEvent thread-safe?  Is it important that it remain thread-safe/reentrant?  The simple way to do that would just be to stick a static char[] inside the function and store the message there.  If different threads might call the function at the same time, though, that could cause problems.

Also, are there repeated messages that _shouldn't_ be suppressed?  The main complaints seem to be about quota messages and "unable to connect" messages, but are there other important ones?

Lastly, I'm not familiar with the IMAP protocol.  Does it have standard names or numbers that accompany warnings of some kind?  If so, that would avoid the I18N issue completely, which would be nice.  The "unable to connect" case could be handled separately, since presumably TB will have some sort of state set when it can't connect.
(In reply to comment #20)
> The simple fix would be to just store the message shown in an in-memory
> variable. If the server sends a message, check against this var, and if the
> message matches exactly, don't show it, as we have already shown it.

I certainly agree that getting a simple but effective solution implemented would be preferable to having a nice idea for a comprehensive solution which won't get easily done, but working towards it should be kept in mind.

(In reply to comment #21)
> would just be to stick a static char[] inside the function and
> store the message there.

That string should probably be kept per account. You want to avoid that a message is repeated for all folders of an account; but, if multiple accounts produce repeated alerts, those would pop up alternately if matched against a global and not their own per-account last alert string.

> I'm not familiar with the IMAP protocol.  Does it have standard names
> or numbers that accompany warnings of some kind?

It usually comes as "NO [ALERT] ...message..." reply from the server,
http://tools.ietf.org/html/rfc3501#section-7.1

(In reply to comment #19)
> As for rsx11m's question about 91% vs. 92%, I think you could just handle it
> with 3 cases: (1) show all quota messages, (2) show unique quota messages, (3)
> suppress all quota messages.

This still leaves the problem of how to recognize a quota string in order to distinguish it from any other server message. Assuming that all IMAP servers report quota in percentages, and that's the only such message, looking for a combination of a numerical value followed by a '%' may already be sufficient.
Assignee: mscott → nobody
The simple thing to do is to display pop ups not as pop ups but as alerts in a yellow bar at the top of the window in the same way that firefox does.
Also, my interim solution:
http://www.johanneshuebner.com/en/clickoff.shtml
I support snsansom in his proposition of replacing modal messages with non-modal messages like in firefox.
This bug is still VERY annoying and doesn't help making TB a user-friendly soft. It exists since tb 1.0 !
Yes, please, please, please can this be fixed. We're coming up to this bug's fifth anniversary!
Oh, I should start shopping for something wood, that's for the 5th anniversary, right?

I think we could try a similar solution to this problem that bug 493043 is going to use.  Likely this will fit in well with bug 492158 (folder summary page)
Please fix this, it's a PITA.  I suspect the quota alert is sent by the server on any access.  This effectively requires me to hold down the Esc key for like 30 seconds to quell the repetitive modal dialogs any time I interactive with Thunderbird.  As you can imagine, this makes it difficult to even delete items to clear up space!  Frankly any application which performs a denial of service on the user like this, I consider broken.
+1 for "I support snsansom in his proposition of replacing modal messages with
non-modal messages like in firefox."  

See also further user frustration at 
http://forums.mozillazine.org/viewtopic.php?f=39&t=271172&start=0
http://forums.mozillazine.org/viewtopic.php?f=31&t=572329&start=0
http://forums.mozillazine.org/viewtopic.php?f=39&t=440389&p=7713075
@standard8: Does the fix in the now resolved bug 123440 cover other modal dialogs as well, or maybe would it be straight-forward now to add a similar option to message types like the one here if not?

(Quoting bug 123440 comment #162)
> Created an attachment (id=437291) [details]
> Proposed fix
> 
> As discussed on tb-planning this patch removes the modal dialogs, but pushes
> the alert to the alert service so it appears in a similar way to the new mail
> prompt so that the user can still know there has been an issue. The modal
> dialogs I'm referring to are the ones that have a single OK button and are
> typically generated as a result of protocol errors.
> 
> The code which logs the message to the activity manager is also preserved so
> that if the user misses the alert, then they can always check in activity
> manager.
> 
> Note that the idea for this patch is based around one that timeless passed to
> me over irc.

So, this would basically translate to "show a non-modal alert whenever a quota occurs and make a note in the activity manager" for the problem here.
Blocks: 242396
Severity: normal → S3
See Also: → 242396
You need to log in before you can comment on or make changes to this bug.