Closed Bug 123440 Opened 23 years ago Closed 14 years ago

Stop that annoying modal dialog when mail can't connect to the mail server from connection time out error

Categories

(Thunderbird :: Mail Window Front End, defect, P3)

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

Tracking

(blocking-thunderbird3.1 -, thunderbird3.1 beta2-fixed)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 3.1b2
Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- -
thunderbird3.1 --- beta2-fixed

People

(Reporter: a1291762, Assigned: standard8)

References

(Blocks 1 open bug)

Details

(Keywords: uiwanted, Whiteboard: [FIXED: COMMENT 166][Please do not comment on this bug!])

Attachments

(2 files)

Please please make the bad man stop
34.56 KB, image/tiff
Details
Proposed fix
1.08 KB, patch
Bienvenu
: review+
clarkbw
: ui-review+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

I have my Mozilla mail open all day so I can see when new messages come in. I
have mozilla set to get new messages from an Exchange POP server every 5 minutes. 

The problem is that when mozilla can't connect to the mail server (it happens
quite frequently), it puts up a confirmation dialog box. Since I am usually
doing something else, and I have virtual desktops (via Litestep) I often don't
notice that the dialog is up. It's not until I try to do something with Mail
that I notice it's not working.

When I click OK, it usually connects just fine.

Reproducible: Always
Steps to Reproduce:
1. Open Mail
2. Make server unavailable (eg. pull network connection)
3. MozMail tries to get mail and puts up a dialog
4. Make server available
5. Moz should go and get new mail

Actual Results:  Moz doesn't get new mail. Mail can't be used until OK is clicked.

Expected Results:  Moz should close the dialog (or not have shown it in the
first place) and get new mail.


I expect this also affects checking news servers.
just so i'm clear, your saying that the biff notification is allowing a dialog
to come up? 
Related/dup of bug 114846
I see the problem here. I already have a fix for it. This seems pretty annoying.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.9
QA Contact: esther → sheelar
I believe I checked in a fix for this along with 122236. I took away the message
window pop biff was using to bring up the alert. biff should never be bringing
up alerts.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
So is this fixed in the newly-released 0.9.8?
nope, this was fixed tonight. So it's in tomorrow's nightly build and eventually
in 0.9.9 when that comes out. 
*** Bug 116852 has been marked as a duplicate of this bug. ***
Yipe-Yipe-Yay! Very glad to verify this bad boy has been fixed. Mozilla
approaches perfection :-)
Status: RESOLVED → VERIFIED
umm.. sure it's fixed? I saw the alert today. But what's more.. it seems when my
mailserver is not responding, the throbber now goes on spinning and hitting
stop-button has no effect..?
In mozilla-win32-1.0 the error is fixed, but in mozilla-win32-1.1a the error
again appears.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Adding a bunch of people who make changes to mail backend code.  I just want to
make sure that nothing we're about to check into the branch caused this.
We should check if the fix for bug 145341 caused this - it was a change to make
sure we see progress messages when mail is auto-downloaded on biff. bug 145341
is scheduled to be checked into the branch.
If you have automatic download on biff on, then we will throw alert. Is that so
in your case ? If it is so, we could do suppress no connection error.
Assignee: mscott → naving
Status: REOPENED → NEW
Checked this on today's branch build:06-17-08 build on win98

I pulled the LAN connection and tried with two options:

Autodownload on biff checked : We show the alert. Connection to the server timed
out alert.
Autodownload on biff unchecked and only check for new messages [] checked: Still
show the time out alert.

The dialogs appear in both cases at the interval set in biff settings.
Also noticed that I had to click twice on the Okay button to dismiss the dlg. 
The first click stopped the throbber activity and the second click dismissed the
dialog.
We do not prompt the user with connection error if you dont'have the
preference"automatically download any new messages" unchecked.  
In my last comments I said we prompt user without the autodownload on biff which
is not true. I probably had another pop account set to autodownload on biff.
So if the user has multiple pop accounts in a profile they should uncheck the
preference "automatically download any new messages" for all of them.  Then we
do not show the connection failed error.  

Adding keyword to release note this bug if any one runs into this problem..
Keywords: relnote
nsbeta1- per mail triage.
Keywords: nsbeta1 → nsbeta1-
Well, as of Mozilla 1.0.1 (Linux) Build 2002082607 this bug is still present...
OS: Windows 2000 → All
QA Contact: sheelar → stephend
Hardware: PC → All
Target Milestone: mozilla0.9.9 → ---
dam stupid comment I have mozilla 1.2.1
This is still happening as of 1.2.1, and is extremely irritating, staining an
otherwise-superb mail client.  In fact, a friend of mine stopped using Mozilla
mail yesterday due to his frustration with this problem, which is what prompted
me to comment.

Several times each day, when an email server denies a connection for some
transient reason or another, I get the popup "Could not connect to ...". 
Clicking on the "OK" button, is not too big of a deal, but then I have to enter
my password for the server again, which is annoying.

I suggest that there be a user-settable grace period of some sort on mail server
errors.  For example, user can say to recheck N times (at the set interval)
before receiving a a popup and having to re-enter muy password.

*** Bug 188899 has been marked as a duplicate of this bug. ***
*** Bug 161167 has been marked as a duplicate of this bug. ***
*** Bug 198354 has been marked as a duplicate of this bug. ***
*** Bug 146518 has been marked as a duplicate of this bug. ***
I have been seeing the popup window a lot less with the 1.3 Final version, when 
I'm disconnected from the net.  So, there has been *some* progress here.

I still get the popup when the connection is on but "frozen" (I'm having some 
kind of weird problem with my dialup, where traffic is basically halted but the 
line stays open).

The following was posted yesterday in netscape.public.mozilla.mail-news, by one 
"Glenn," in the "Auto-dismiss Alert Dialog Box?" thread"

> I'd like to see the asynchronous, user-intervention required, alert box 
> completely suppressed.  To me, an appropriate alert would be to change 
> the color of the account name in the list of accounts... it would stay 
> in the error color until either
> 
> (1) it came time to check the account for mail again, according to the 
> configuration... if the next check is successfuly, the previous error 
> can be discarded, and the color returned to normal.... a transient error 
> has been encountered.
> 
> (2) the user selects a folder for that account, or the account itself. 
> At that time, the error encountered could be reported as an alert box, 
> and the color returned to normal.  (This would be a synchronous alert 
> box... synchronized with user activity.)
> 
> The net effect of these changes would be that mail would hum along 
> checking (as Mike suggests), so that as much email as possible is 
> collected when the machine is unattended (for example) or the user is 
> busy with other activities, other accounts, or web browsing (more 
> examples), yet persistent errors would still be seen by the user when 
> they get a chance and wish to be actively involved with the account of 
> concern.

In my opinion, this is the correct design, and ought to be implemented as soon 
as feasible.
mass re-assign.
Assignee: naving → sspitzer
*** Bug 167790 has been marked as a duplicate of this bug. ***
Sometime between 0507 and 0516, this problem has backslid a little -- the
annoying box is popping up when the dial-up connection has been terminated,
something that had gone away back in April.
I agree that my bug #186952 is a dupe of this one.

However, I would suggest that the alert dialog window be replaced with a little
popup alert that goes away after a few seconds, and the condition is logged to a
log file for later review, if the user sets logging.
*** Bug 186952 has been marked as a duplicate of this bug. ***
My recommendation is:

do NOT intervent user action by popping up dialogs when the user has not
actively initiated the action which produced the error dialog (eg. not pressed
the "get mail" button, or the browser did not find the start up page). This is
to some extent the same as with pop up windows (advertising) on web sites.
Instead display an error icon on the status bar that opens an error log for
non-interactively produced errors.

That is something Outlook does very nice. *g*
we should not be putting up that alert when pop biff fails, end of story.
Putting up a status message on the status bar would be nice, perhaps, but the
important thing is not to put up that alert. Taking.
Assignee: sspitzer → bienvenu
To follow up on my comment 27: the 'regression' went away again in a build
shortly thereafter, and is not present in 1.4 Final.  If my dialup connection is
down, the biff does not put up the alert; my server has been well-behaved of
late, so I haven't seen the alert box in some time.
Keywords: relnote
See also bug 82999 which is related.

What should happen here is that only one dialogue PER ACCOUNT should be
presented, not one per folder.  And once the first has been presented, the
account should revert to the pre-poll state. 

That is...  if I set all my accounts to "do not check on startup", then they
wake up in a no-poll state.  Loss of connection should revert them to no-poll state.

And I also wish that I could click on the letter icon to manually set an account
to a no-poll state.

Note that a comparable problem appears for mobile machines.  From position 1, I
can reach server A but not B.  From position 2, I can read B but not A. 
Switching currently requires quitting and restarting, or crashing mozilla if I
forget.  (several hundred folders polled, 2-3 minute poll intervals - I can't
close all the dialogues before new ones are spawned).
(In reply to comment #30)
> do NOT intervent user action by popping up dialogs when the user has not
> actively initiated the action which produced the error dialog (eg. not pressed
> the "get mail" button, or the browser did not find the start up page). This is
> to some extent the same as with pop up windows (advertising) on web sites.
> Instead display an error icon on the status bar that opens an error log for
> non-interactively produced errors.

Yes, agreed! That is a good general policy. For me, it is really annoying to
click away up to 30 popup windows telling me, that my mail client could not
check messages over night. IHMO, one window telling me should be enough!

The best would be a configuration item to tell Mozilla mail whether I want to be
alerted by an alert box. And until the user does not click OK, no more alert
windows are popped up (for this account). This also relates to the approach in
comment #33.

Please, stop that inflation of alert windows!

Thanks, Jörg


*** Bug 232134 has been marked as a duplicate of this bug. ***
*** Bug 244491 has been marked as a duplicate of this bug. ***
This dialog/alert is a problem for IMAP servers too; updating summary.
Summary: Stop that annoying dialog when mail can't connect to the POP server → Stop that annoying dialog when mail can't connect to the mail server
Two suggestions for communicating the alert to the user from 244491 (apologies
for dupe, I searched on "modal"):

1) for integration with both firefox and thunderbird I see either a sidebar, or
something like the download manager, which shows queued alerts, where each can
be acknowledged as necessary.

2) for thunderbird only - it's a message system so why not "deliver" the message
 into a mailbox, either a box that exists already or a virtual one for alerts.

This bug was raised in the beginning of 2002, and in the middle of 2004 this bug
is _still_ present.

Mozilla v1.7 repeatedly pops up a dialog (for reasons covered in _many_ bug
reports) saying "Server <hostname> has disconnected. The Server may have gone
down or there may be a network problem."

I as a user have no care in the world whether a server has disconnected. I only
care if a server cannot connect, which is a problem far more worthy of a user's
attention.

Please please can someone remove this annoying dialog entirely, so that I can
return to sanity. It should either be ignored as a recoverable condition without
human intervention, or appear as a warning on the bottom status bar.

I believe the severity of this bug should be increased to "major", as it is a
serious usability problem.

(In reply to comment #39)
> I believe the severity of this bug should be increased to "major", as it is a
> serious usability problem.

That wouldn't attract more patches to this bug. As with all cases of resource
limited projects, there are priorities to be fullfilled. In the meantime, you
may try Thundebird. It doesn't exhibit this bug.
*** Bug 256146 has been marked as a duplicate of this bug. ***
*** Bug 267192 has been marked as a duplicate of this bug. ***
(In reply to comment #40)

> As with all cases of resource
> limited projects, there are priorities to be fullfilled. In the meantime, you
> may try Thundebird. It doesn't exhibit this bug.

Aside: Wouldn't elevating it to "Major" mean it would become more of a prority?
 The impression I got was that Graham understands the priority thing and is
hoping to see this prioritized.

Focus: I'm *still* getting an "annoying alert box" and a flashing StartBar tab
whenever one of my mailservers is unreachable - i.e. the confirmation dialog box
mentioned in the original description is still very much present in one of the
most recent nightlies (build 20041025).
Product: MailNews → Core
*** Bug 287270 has been marked as a duplicate of this bug. ***
*** Bug 333183 has been marked as a duplicate of this bug. ***
Wow, 4 years since the first complaint and tons of complaints since, and this small bug isn't fixed yet. Hate to be rude, but that's pathetic.
I believe this was fixed a long time ago - if it's the check for new mail that discovers that mail server is down, it doesn't put up an alert. Only if you explicitly try to get new mail by clicking the get new mail button do we pop up the alert (or at startup if you automatically get new mail at startup)
(In reply to comment #47)
> I believe this was fixed a long time ago - if it's the check for new mail that
> discovers that mail server is down, it doesn't put up an alert. Only if you
> explicitly try to get new mail by clicking the get new mail button do we pop up
> the alert (or at startup if you automatically get new mail at startup)
> 

Not true. I'm using the latest TB (1.5) and have it set to automatically check for mail every 5 mins, and very often (I'm guessing about 80%-90% of the time) on the 5 min mark TB is suddenly unable to connect to any of the servers and throws up all the nag boxes that I have to click. Usually after clicking all of the nags I can immediatly do a manual "Get all" click, and it mysteriously finds a way to connect without error. Please refer to my dupe bug mentioned in comment #45.

If it werent for this huge bug I consider TB to be a perfect email client. I've used countless email apps, (Eudora, Outlook, Outlook Express, Forte Agent, The Bat, and numerous others) and this is the only client I've seen do this type of notice when it cant connect. All others do it in an unobtrusive way. It baffles me why the TB devs chose to do this.
Er, as a TB developer, I've chosen not to see alerts about server down on check for new mail, and I don't see them. So perhaps you could give some details about the problem you're seeing, like first of all, are you using IMAP or Pop3 servers?
(in reply to comment #49)
How do you make the choice not to see the popup errors?
Is that choice also available in SeaMonkey? I couldn't find it there, but maybe I'm not recognizing it for what it is.
I don't see such errors for most of my accounts, but I do see it for one account now, for which the server is half-down... it went down completely, but now is up but not accepting connections... and I get popups when I first start SeaMonkey... takes either 1 popup or 6 popups each time I start, and then I don't hear from that account for the rest of the session.
>How do you make the choice not to see the popup errors?

By "chose", I meant I chose to change the code so that it wouldn't put up the popup errors when it was just the periodic check for new messages that was failing. That was years ago, and was what I believe this bug was initially about.

It sounds like you're seeing this because you've configured the account in question to download new messages at startup (tools | account settings | server settings | check for new mail at startup - if you turn that off for the account you're having trouble with, you shouldn't see that alert). We inform the user of that error on startup because we think the user wants to know that, and we assume they're not starting up TB unattended. Besides being generally very annoying, having that alert firing when doing the periodic check for new mail is especially bad if TB is left unattended, because that alert tends to block other operations.

I don't know why you'd see that alert six times for one account - do you know if it's a pop3 or imap account?

I agree that something less annoying than the alert for your situation would be better, but I was just pointing out that what this bug was initially about has been fixed.
(reply to comment #51)
Indeed; it seemed like a similar situation, so I hoped perhaps my input regarding this failing server would shed some light, not sure whether it was in support of the bug being fixed or not being fixed!

The account of concern is POP3; and is configured for check at startup.

When the server doesn't respond at all, there is only one popup.  When the server rejects the login credentials, it seems that is when there is the probability of 6 popups before things quiet down... with the credentials rejection, it ususally takes 6 popups, but sometimes only one.  This particular server is in an extended period of downtime, it seems.

While we are one the subject, when the background errors are suppressed to perform no popup, is there any other indication that the error occured, and if so, where would that be found?

For most of my accounts, I actually run them through ChoiceMail, which is a local POP/SMTP proxy that sorts out the SPAM and suppresses (but logs) any error conditions.  That is, SeaMonkey is always successful talking to the proxy; the proxy logs errors encountered talking to the real servers.
For me, the dialog box is happening on the periodic check rather than the startup check, even though I do have check for new mail on startup selected on all of them. 

All of them are pop3 accounts, a handful of them are using the gmail pop3 accounts to check gmail through TB. The mail checking on startup seems to almost always complete fine. It's just the periodic check that it happens on. Its the "Cannot connect to server" error and it says the pop3 server name. 

Other than that, I'm not sure what other information to provide in order to help get this fiexed, as I believe I've pretty much said everything in my duplicate bug that I mentioned earlier. If you need to know anything more that may help, please ask exactly what. I am more than willing to provide any info.
I also just noticed another dialog box popping up for every account doing the exact same thing, when the connection to the server times out. Same effect: the program won't continue checking email as scheduled or continue otherwise in any way until I go through and click all of the OK buttons. =/
when you say "periodic" check, you mean the automatic check that happens without you pressing get new mail, right? Because in the dup bug you referred to you talk about clicking the get new mail button.
(In reply to comment #55)
> when you say "periodic" check, you mean the automatic check that happens
> without you pressing get new mail, right? Because in the dup bug you referred
> to you talk about clicking the get new mail button.
> 

OK, to clear things up, here's how my TB is setup. I have it set to check for all new email for all accounts on program startup, and also have the checkbox checked for each account to automatically check for new email, and it's set for 5 minutes. The latter is what I meant by periodic check.

With that said, these dialog boxes (with modal) popup during ANY of the mentioned conditions. Whether It is checking during the periodic checking OR when I manually click the Get/Get All button, and on the checkign on startup. Simply put, whenever it checks for email and cannot connect to an email server or the connection times out, the dialogs popup. It would be so much easier if a TB dev would simply completely remove this dialog box and move the error messages to the statusbar, or something, and let the program naturally continue on its merry way with no user interaction.

If only I were a C+ coder. I am a VB coder and run a small shareware company, so I know how simple of a change this is to make. I'd have it done in 10 minutes. =)
*** Bug 223131 has been marked as a duplicate of this bug. ***
Please take a moment to have a look at the patch posted for the duplicate bug 223131:

https://bugzilla.mozilla.org/attachment.cgi?id=153463
https://bugzilla.mozilla.org/attachment.cgi?id=153463&action=diff

It seems to be pretty un-bit-rot-able ... comments, anyone?
*** Bug 345953 has been marked as a duplicate of this bug. ***
Eyal in comment #58:
> Please ... have a look at the patch posted for the duplicate bug 223131:
> 
> https://bugzilla.mozilla.org/attachment.cgi?id=153463
> https://bugzilla.mozilla.org/attachment.cgi?id=153463&action=diff
> 
> It seems to be pretty un-bit-rot-able ... comments, anyone?

Appears so.
Mark Stier, the patch author, is here.
Summary: Stop that annoying dialog when mail can't connect to the mail server → Stop that annoying dialog when mail can't connect to the mail server from connection time out error
Nukey, Glenn, does this problem still exist in version 2?  Should bug be closed?
Yes, it is still there. At least for the email accounts. The RSS-feeds works perfectly in this sens.

I miss an error report window. On the status bar can be written: "Error on 3 email accounts, 6 rss-feeds" on anything like this.

(In reply to comment #62)
> I miss an error report window. On the status bar can be written: "Error on 3
> email accounts, 6 rss-feeds" on anything like this.

Outlook (Express) does it nicely, with an icon to show there was an error, clicking on it opens a non-modal dialog.
Keywords: uiwanted
Summary: Stop that annoying dialog when mail can't connect to the mail server from connection time out error → Stop that annoying modal dialog when mail can't connect to the mail server from connection time out error
QA Contact: stephend → backend
I don't really agree that my Bug#407906 is a duplicate, especially when I find in 2007-12-10-03-trunk a bug that was addressed years ago.  However, today I find a very interesting variation using 2007-12-15-03-trunk.

Started downloading a big batch of mail.  After a few hundred the network connection timed out (as it has been every time for 2 weeks).  I dismissed the dialog.

However, when I went to the xterm where I was TAIL-ing the NSPR_LOG_FILE, the download had apparently restarted and the program was back in the LIST, UIDL, etc. state.
As of this time (about 8 hours later) the download is still going on at a snail's pace and the program does just what I suggested in 407906.

But something is lost: there is no "downloading message 3000 of 9000" status line, and the "Stop" icon is greyed out.  It almost seems some parts of the program don't know the download is in process.  This impression is strengthened when opening a second folder attempts to start a download (and gets a folder-busy error).
I can add a bit.  (Same comment is on Bug#407906, but who's gonna look there?)
The following observations are based on over 2 weeks of observation.

If I start the download manually (Click Get Mail from ...), then the status bar displays the progress -- slower than one might like on a 500+K/sec broadband but it is progress.  And it consistantly times out before completion.  The number of messages received before the timeout is not at all consistant.  I have not yet been able to verify if there's anything consistant about the last message received before the failure.

If, however, I do nothing and let the "Check for mail every [10] minutes" timer initiiate the download, then:
(a) There is no status bar display (bug or feature?), and "Stop" is greyed-out;
(b) Either the connection doesn't time out, or it restarts the next time-interval.  I'll know which on Monday.

Also, if the NSPR_LOG is correct, the timeout always occurs at a point when I would not expect the program to be waiting for a network message.  I have not yet seen a timeout occur between RETR and ".", nor between "DELE" or other command and the associated "+OK" or "-ERR" status response.  It always seems to be between the "." end-of-message and the expected "DELE" command.  Of course, by now I have over 100meg of NSPR_LOG to check before I'm positive of that. Maybe somebody who knows the code can verify that the NSPR_LOG line for SENT: <command> .... is written just _after_ passing the command to the network; that would confirm that the program isn't even in a receive-state when this bogus timeout occurs.
David, it could be that you have a server that's lying about the size of messages, so we expect more data to be sent back, and it's not ever going to come. In other words, just because there's a '.' doesn't mean the server has sent all the promised data.

Have you changed the value of mail.server.default.dot_fix, or dot_fix for any server? It should be set to true, in which case we do try to assume that a line with a stand-alone '.' is the end of the message even if the server promised more data. Perhaps that code is broken, but it looks ok...
(In reply to comment #67)
> David, it could be that you have a server that's lying about the size of
> messages, so we expect more data to be sent back, and it's not ever going to
> come.

Not impossible.  But then, how come the behavior is different depending on whether the download is initiated manually or by the timer?

Checking the STD0053:
<blockquote cite="ftp://ftp.rfc-editor.org/in-notes/std/std53.txt">
It is important to note that the octet count for a message on the
   server host may differ from the octet count assigned to that message
   due to local conventions for designating end-of-line.  Usually,
   during the AUTHORIZATION state of the POP3 session, the POP3 server
   can calculate the size of each message in octets when it opens the
   maildrop.  For example, if the POP3 server host internally represents
   end-of-line as a single character, then the POP3 server simply counts
   each occurrence of this character in a message as two octets.  Note
   that lines in the message which start with the termination octet need
   not (and must not) be counted twice, since the POP3 client will
   remove all byte-stuffed termination characters when it receives a
   multi-line response.
</blockquote>
I see the potential for a problem created by "lines in the message which start with the termination octet."
What I don't see is any possibility that a line consisting of a single "termination octed" -- "." -- would NOT be the end of a transmission.



 In other words, just because there's a '.' doesn't mean the server has
> sent all the promised data.

Please clarify.  It's hard to see how that would legally occur.
 
> Have you changed the value of mail.server.default.dot_fix, or dot_fix for any
> server? It should be set to true, in which case we do try to assume that a line
> with a stand-alone '.' is the end of the message even if the server promised
> more data. Perhaps that code is broken, but it looks ok...

That looks like a hidden pref.  I've never touched it, because I never heard of it.  Perhaps you could point me somewhere appropriate?  I can try any reasonable experiment, but I presently lack the diskspace to to a compile.

The more I look at this, the more it looks as though the problem for me is NOT how Thunderbird reacts to the problem, but that the timeout occurs at all.  Of course, I rather despise modal boxes when there's nothing the user needs do to correct the situation; so I'll stay on this bug anyway.  More later if I can dig anything useful out of all these logs.
(In reply to comment #12)
> We should check if the fix for bug 145341 caused this - it was a change to make
> sure we see progress messages when mail is auto-downloaded on biff. bug 145341
> is scheduled to be checked into the branch.

David, this was a long long time back.  But note that "progress messages when mail is auto-downloaded" is precisely what I'm NOT seeing when the download succeeds.
I'm the "glenn" from comments 24 and 52.  I've switched around my email, to mostly using gmail, and thus with gmail's great anti-spam, no longer use the choicemail proxy.  And, gmail now implements IMAP, so I've converted my accounts to use IMAP.

Unfortunately, with my current ISP, it seems to flake out on some late afternoons (overload?) and so I am again being annoyed by the pop-up password prompts when the connection fails.

I still believe the interface in comment 24 is a reasonable design, although there may be other reasonable designs.  Unfortunately, it seems that no such design has yet been implemented.

Since comment 24, I have become much more aware of security issues and trojans, as they continue to proliferate.  I now firmly believe that no software should pop up any dialog asking for password information asynchronously... it should only ever request password information if the user initiates an operation that requires the request.

It would be better if Password Manager (or even better, if Account settings) had a way to allow the user to store/change the stored password.  Any "authentication errors" returned from the server should be treated as transient errors, and retried at the next automatic interval with the same stored password.

Perhaps, to deal with people that change the password on the server without concurrently changing it on their clients, and for whom the server might lock them out after several failed attempts, a setting should be provided to not retry at automatic intervals, but rather to mark the account as having encountered an error, and suspend automatic retries.
Glenn, I strongly support your suggestions below. It is not only annoying that
a password dialog pops-up if only the mail server connection is temporarily unavailable (same happens for me with a free-mail IMAP account), but also a 
potential security issue.

Therefore, I would like to ask to implement that feature in a similiar way as described below.

Many thanks, Jörg

(In reply to comment #71)
> [...]  I now firmly believe that no software should
> pop up any dialog asking for password information asynchronously... it should
> only ever request password information if the user initiates an operation that
> requires the request.
> 
> It would be better if Password Manager (or even better, if Account settings)
> had a way to allow the user to store/change the stored password.  Any
> "authentication errors" returned from the server should be treated as 
> transient errors, and retried at the next automatic interval with the same 
> stored password.
> 
> Perhaps, to deal with people that change the password on the server without
> concurrently changing it on their clients, and for whom the server might lock
> them out after several failed attempts, a setting should be provided to not
> retry at automatic intervals, but rather to mark the account as having
> encountered an error, and suspend automatic retries.


This is similar to bug 121647 , Although that is more specific to the problem of losing passwords when a new one is erroneously requested. (I.E. Temporary connection fault)
Both bugs could possibly be solved together.
This bug has been present since 2002 - it annoys users so much that 21 of them have independently reported it as a bug, in addition to all those who found the initial bug report and all those who have commented above. All that is needed to fix it is an option to suppress a dialog box. Is anyone actually working on it?
Flags: wanted-thunderbird3?
This is the only bug I have ever voted on because the incessant popups disrupt my work so annoyingly.

I've nominated it for wanted-thunderbird3 because I think we need to fix it finally.
Flags: wanted-thunderbird3.0a2?
kill dialogs, kill.

assigning to bryan for a UI plan to start.
Assignee: bienvenu → clarkbw
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3.0a2?
Flags: wanted-thunderbird3.0a2+
Flags: blocking-thunderbird3+
Product: Core → MailNews Core
Bryan, I have some thoughts on how to change the backend to send notifications that the front end alert displaying code can listen to instead of putting up alerts - do you have thoughts on what we should use in the front end to display the messages? davida mentioned the weave notification system. There's also the info bar...
David, I've been looking at a couple possibilities for notifications.  Here are the general frameworks as I see them.

- Indication on the Account in the folder pane -

I think there needs to be a subtle indication that an account in your folder pane is not connected or receiving messages.  This allows people to know that the indicators for new messages mail not be correct anymore.  I'm not sure where to put this kind of indication because it is account wide, not just the Inbox or folders; yet placing the indication on the account item would lead people to click on it and mean we'd have to provide a message somewhere in that HTML account page.  Also, bug 446306 getting implemented might mean we need to wait on this piece all together.

- Indication in the thread list view - 

I think we can place an info bar at the top of the thread list area to indicate that the list of messages you're looking at is from an offline account.  I think our only available action show be ( Try Now ) and we should be listing the countdown until the next time we are going to automatically attempt to reconnect.  

( see http://clarkbw.net/blog/2008/05/13/a-bit-of-a-communication-problem/ )

If the person closes (x) the info bar we should probably continue to hide it in every other thread list ( like other account folders ).  I think we'll need to try it out a bit to see what works best.

: Just thinking out loud, maybe we use the same info bar above the account HTML overview page such that we can put an indicator by the account and give some context / actions to perform. :

- Indication of connection error in messages -

I need to file another bug for this, but we shouldn't be filling the message (view) reader area with text about how things are offline.  We should be creating a message with the headers and using the blank content area for actions to get back online or change offline settings... blah blah blah.

- Offline notification bubbles -

I'm a bit unsure about popping up anything to indicate that an account went offline.  If you're not in the account and thus can't see the info bar or other indications of offline status then a small popup could be useful.  At the same time I think we can do a less intrusive indication with a little color animation on the account folder pane area.  By pulsing a color (like a red shade) on the account indication one time we can show that something not so good happened.

I've ignored the total offline state in all these sections because I think that should be handled differently.  When you are completely offline we don't need to indicate that individual accounts are offline as well, that would just be annoying.  Total offline requires indication of your online/offline state that are constantly visible and indications when you try to send or receive mail.

That's about everything I have so far, I'd love to get some thoughts and feedback.
In general, I like where you're going with this, but I think we're talking about slightly different things. Most of what you're describing seems to me to fall into what now is silent failure (e.g., biff failing, so the account is offline). The current state of affairs is that, for the most part, we don't put up alerts unless the user has explicitly done something (e.g., biff does not put up alerts on connection errors, but bonking the get new mail button does). Would you have different feedback mechanisms for those two cases? E.g., maybe an info bar for the latter, and your subtle indication idea for the former? Startup with automatic download is somewhere in between - we do put up alerts for that, but the subtle indication idea might be better for that situation.

Then there are a whole bunch of other operations that cause connections that can fail. Keeping in mind that we already automatically silently retry operations, how should we handle feedback for those? If trying to read a message results in some sort of error (e.g., the network is alive, but the server is down), would we display information in the message pane about the error?

An other point of pain for users is IMAP alerts, e.g., quota alerts. IMAP requires us to show those to the users, which to me indicates that something like an info bar is needed, since we're supposed to show the actual text.


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

Note that the system will throw multiple error message * immediately after each other* under some configuration! This will send a *stream* of alerts (to call it that way) and pester the user into clicking over 40 times OK just to get the dialog box out of the way.

This is different from the "every 5 minutes a warning" box.
I see, in general I think where we can silently fail and reconnect we shouldn't be using info-bars or animations to tell the person what happened.  I imagine there needs to be some kind of judgment in the code that determines when to let the user know we haven't been able to contact the server successfully in a certain amount of time.  I'm not exactly sure what events or what length of time is correct as I don't really know many of them.  Perhaps something like this is what the dialog code is already doing?

For everything else where an action the user requests requires us to report the connection failure to them I think we need to start placing those errors inline.  Very similar to what Firefox did with their connection and timeout errors that used to be dialogs. 

Here's a sample of how we could represent the error of connecting to a mail server and retrieving the message body.  The error is clearer because it's directly related to what the person wanted to do.  And we state why the error happened, how we're trying to fix it and how they could fix it faster if they know more than we do.
http://clarkbw.net/designs/msg-reader/std-msg-reader-conn-error.html
Regarding comment #85: I partly agree. I have been coming from an Outlook 2003 in Exchange Server mode configuration, and I quite liked the defaults they provided (or I have adapted to it). Microsoft should look at Thunderbirds performance though, especially with LARGE mail folders (>2000 or even >20000 mails). On the other hand you can borrow a lot from what they have done in their products on the 'error handling towards the user'. I believe its quite well designed.

I do like the suggestion on your draw up. I would make it more 'quiet' by dropping the counter, though. The idea of period retry is good though. Adding an friendly explanation with some possible steps that should be taken to resolve the problem (e.g. check your network connection) is good for most users, I believe.

Important to me seems some indication of what the current state is. I like to know that I'm offline or whether the software is disconnected or connected. Integration with "minimize to tray" plugin and the status bar seems a good idea to me. This would provide an interface to background tasks. Futhermore it would allow the system to get the mail from offline store, so I can read it, while still showing that there is a problem somewhere.

In that paradigm it seems useful that provide a well-defined interface for handling errors. This would include tracking whether tasks are automatic, user-initiated or special (handle itself) in another way. I know too little of Thunderbird its architecture to say anything about how I would probably implement it. There seems a good chance that error handling to the user is buried deep down. I believe Outlook lets components report and later pulls up the error reports. There are also cases when this happens in Thunderbird (send mail, but can't contact SMTP or IMAP server).

I do believe there are quite a lot of hazards in regard to "what we believe our users would want". The configuration interface seem under-utilized (in fact, lots of really useful things are buried far away in the "config editor"). The desirability of warnings depends on the user. If email is really critical they want to know or should be able to notice it fast. For most people I agree they will be looking at email when they desire and its good enough to know they are missing the service at that time.

Regarding comment #82. I do still see warnings on background tasks. I also would desire warnings on explicit instructions (feedback is good). I do not like when it warns me for every folder it is checking (that would be over 40 times with the same error in my case).
errors on displaying messages is only one of a large number of operations that can cause errors, so we need a mechanism for handling all the other operations that need error reporting. In many cases, silently retrying (which we do already in the case of connection problems) does not make sense. For example, if you're over quota, copying a message again isn't going to help, and the user needs to get told about the server message.
Re: comment #86: In general, I haven't been able to get past Outlook's failure to report the actual server message, replacing it with numeric codes and other meaningless gibberish, to determine whether their process of reporting errors is useful... when the messages are obfuscated, the process seems bad, even when it is good.

One comment regarding the process is that it has been reported to me by an Outlook user that in order to actually see what messages Outlook does produce that they have to click the icon while it is active, or they miss the messages.  But they might have just not figured out the way to see the messages later, if there is one.
I know this comment is not very useful but this bug is one
of the most annoying things in Thunderbird. The worst thing
is that the modal dialog (=> bouncing dock icon) shows up
even if I told TB to quit.
If the user tells TB to quit it should save unsaved changes
locally and *just quit* instead of having the user press
escape 20 times and finally kill the process.
David, what are the other operations?  

It seems like it might be difficult to have a single error reporting system for all the operations, however we might be able to reuse many of them depending on the type of operation.

File operations, move, copy.
Folder operations, empty trash?
Mail operations, save draft (remote), send mail

If there is a list of these I can start working through some of them to move the errors into the inline operations that caused them and away from the dialog.
In the imap case, every operation that talks to the server can fail, so in addition to the above, 

get new mail
change msg flag (mark read/unread, star, etc)
add/remove tags
read a message
save as
save attachment
subscribe/unsubscribe

And any time we talk to the server, it can tell us to put up an alert, completely independent of whatever the operation is. The quota alert is an all too real world example of this. And we can't assume that the operation the user performed has anything to do with the quota alert - the server is just taking advantage of the fact that we're talking to it to send us the alert. And with IDLE support, the user can be not doing anything at all.  So we need a mechanism to display these alerts completely independent of what the user is doing (connection errors and quota alerts are the two biggest source of complaints about these modal alert dialogs, so we need to fix both, I think)
I'm trying to summary what is mentioned before, and hopefully it will provide some help is designing error handling. Corrections and suggestions are welcome.

There seem to be several cases that can cause errors:

* User initiated (pressing a button).
* Background processes (Thunderbird initiated, e.g. check for mail every 5 minutes).
* Mail Server signaling (from Comment #91, quota alert as an example).
* Fatal errors: Something that should NOT ever have happened (bugs, corrupt mailbox files, ...).
* ???

The most common remark, and the one that put this bug forward, is that people do *not* want to be *interrupted* from work when an background process fails. Signaling such errors range from silently ignore to small icon somewhere to full error message. In general either ignoring or non-intrusive signaling is highly desired.

If the user initiates an action, the error handling is more vague:
* For e.g. reading a message, its suggested to show the error message in the message window.
* For e.g. send, copy, (un)subscribe, ... its desirable to show an error popup to the user.
* What for "Offline -> Download/Sync Now..."?

There is however a consensus that more than one "can't connect to server" message is undesirable!

There is a high desire for USER READABLE error messages (I agree, this is where Outlook goes wrong with its numbers). It should help novice users and prevent them from calling 'technical support' or 'filing a bug' (with the exception of spelling mistakes ;)).

How about retries? While restoring a lost connection seems a good idea (think of roaming users), is retrying in general? I believe there are currently some special cases that are already hardcoded and can probably be left alone.

What about server signals, such as "over quota"? Should this popup, as its more or less a 'background process'. Should this throw a notify icon something?

Some other loose ends?
* Are notify icons good or will they go unnoticed?
* Are non-modal dialogs a good idea, as they are more visible than icons?
  - Should such dialogs come in front of Thunderbird but not other applications?
* What can be silently ignored?
* If we can resolve a situations (e.g. repaired mailbox file), should we signal a warning somehow? For "connection restored" we should not.

As another user noticed: when should error messages be retired? How can we know a certain condition is no longer valid? It seems simple for "server unavailable", but much harder for a lot of other functions (think quota alerts). For dialog boxes its simple: when the user says so...

Also, when are errors duplicate: when they concern the same logical thing (e.g. a server connection) and how to decide when to group them?

In other words, how can we classify errors that come up? If we can do that, we, in principle, know how to handle them...

(In reply to comment #92)
> * ???

Let's not try to dig for more cases, we have plenty, and there'll be other bugzilla bugs if/when this is fixed.

> There is however a consensus that more than one "can't connect to server"
> message is undesirable!

More than one + when it's not user-initiated even one is too much.


> How about retries? While restoring a lost connection seems a good idea (think
> of roaming users), is retrying in general? 

It's a good idea in many cases if not in general, so it should at least be preffable. Argument it's a good idea in general: Many failures are temporary, and when they aren't and the user notices the continued failure, s/he will disable getting new message for this account (at least Seamonkey users will, TB users I dunno).

Here's another idea: Exponential back-off in retrying.

> What about server signals, such as "over quota"? Should this popup, as its more
> or less a 'background process'. Should this throw a notify icon something?

Neither. It should be an info bar at the top of the message list (a bit like the msgNotificationBar or the relevant firefox/toolkit widget).

> * Are notify icons good or will they go unnoticed?

They go unnoticed unless they're not just icons but also text, and there's color involved (green = ok, red = bad).

> * Are non-modal dialogs a good idea, as they are more visible than icons?

No, they aren't, especially when you have many of them.

> * If we can resolve a situations (e.g. repaired mailbox file)

There's mbox auto-repair? That's news to me.

> As another user noticed: when should error messages be retired? How can we know
> a certain condition is no longer valid? It seems simple for "server
> unavailable", but much harder for a lot of other functions (think quota
> alerts). For dialog boxes its simple: when the user says so...

Not so simple. What if the connection failed, then succeeded again on retry? Does the user care about the transient failure? Suppose s/he hasn't been at his desktop for a while.

> In other words, how can we classify errors that come up? If we can do that, we,
> in principle, know how to handle them...

Ah, where's xconsole when you need it...

> 


It'd be good to have a handle on some of the dialog/notification issues in by b2.
Priority: -- → P1
Whiteboard: delight
Target Milestone: --- → Thunderbird 3.0b2
I recently added a new mail account to Thunderbird (2.0.0.16) and set the old one  to never check for new messages (unchecked both "check for new messages" boxes).  But I still get the "unable to connect to server" dialog box several times a day.  I don't know why it's trying to connect to the server in the first place, but I certainly don't want it to complain to me about it failing when I didn't want it to try anyway.
This problem now makes SeaMonkey 2.0a1 almost unusable for me.

I have several mailboxes, one inside my company's network, one inside my client's network, and always one of them is unreachable (separate profiles don't work because I need access to both sets of cached messages).

I have disabled the settings
   "Check for new messages at startup"
   "Check for new messages every N minutes"
I still get the the disruptive modal pop-up 2 or 3 times in quick succession approximately every 3 minutes.

Please provide at least an option to turn this <CENSORED> thing off!

A nicer mode of notification would be to display a red warning "unreachable since ..." next to unreachable servers in the server/mailbox pane instead of interrupting the user all the time.
I'm assuming this is dependent on at least part of the activity manager landing for Beta 1, at least the UI part so we can display status messages to the user w/o using the modal alert. Should this stay blocking b1, or should we move it to b2?
Whiteboard: delight → delight [requires activity manager?]
moving to b2 because we're not holding b1 for the activity manager.
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
Depends on: activitymgr
Whiteboard: delight [requires activity manager?] → delight [requires activity manager?] [no l10n impact]
This isn't going to get traction for the b2 time frame.  bug 257942 just landed with the initial activity manager code; which still needs theme work done.  we also have bug 476487 for the status bar that hasn't been started.  Bumping to b3 as this is still an important point to track.
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b3
Does this bug is fixed? It was added in 2002 and now, in 2009, in my up-to-date thunderbird this problem is still present.

It makes me mad when at all presentations out of the office I have to close 10 modal dialogs first. Moreover some windows appears immediately, some after some time...

I suggest to resign from all such modal dialogs, for errors you should open additional panel in regular interface and show queued error messages there.
Lukasz: the bug still remains open, therefore it's not yet fixed; https://bugzilla.mozilla.org/page.cgi?id=fields.html#status.
Taking, this bug will probably depend on several others.
Assignee: clarkbw → bugzilla
Depends on: 481431
Whiteboard: delight [requires activity manager?] [no l10n impact] → delight [requires activity manager?] [no l10n impact] [b3ux]
Depends on: 476696
No longer depends on: activitymgr
Whiteboard: delight [requires activity manager?] [no l10n impact] [b3ux] → delight [no l10n impact] [b3ux] [needs bug 476696 and its deps]
Whiteboard: delight [no l10n impact] [b3ux] [needs bug 476696 and its deps] → [b3ux]delight [no l10n impact][needs bug 476696 and its deps]
Whiteboard: [b3ux]delight [no l10n impact][needs bug 476696 and its deps] → [b3ux]delight [no l10n impact][needs bug 476696 (poptarts) and its deps]
Blocks: 94228
Whiteboard: [b3ux]delight [no l10n impact][needs bug 476696 (poptarts) and its deps] → [b3ux]delight [no l10n impact]
Priority: P1 → P3
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
Target Milestone: Thunderbird 3.0b4 → Thunderbird 3.0b3
Modal "can't connect" dialogs are a big problem, especially since with 4 accounts in Thunderbird, you get 4 dialogs to click away before you can do anything! (Usually click "check mail", ironically!)

You know that non-modal "remember password dialog Firefox 3 introduced?[1] Thunderbird could have something like that.

The message could be (approx. the same as now): "Couldn't connect to mail server".
And the buttons could be: "Re-check mail", "Dismiss"[2] and (maybe) "Show connection-log".

A "Never tell me again" button wouldn't a great idea, as everyone still wants to know if non-mail is because there's no mail or if there's no connection.

So please, please, fix this issue (after 7 years), I'm sure users everywhere would appreciate it.

[1] http://www.mydigitallife.info/wp-content/uploads/2008/07/save-paypal-password.jpg
[2] Or something to that effect. Don't take my wording of the messages too literally.
Actually, while we're at it:

The "send mail dialogs" actually also need to be part of the 'activity manager',
or at least non-modal, and part of the main Mail & Newsgroups window.
This would let you get on immidiately with writing or reading the next mail message.
jjm: the new send in background does what you're talking about, bug 440794
Target Milestone: Thunderbird 3.0b3 → Thunderbird 3.0b4
(In reply to comment #112)
> jjm: the new send in background does what you're talking about, bug 440794

Great, but I'm a bit concerned that it'll be displayed in a separate window (much like the FF download window), thus taking the focus away from the main window. I mean that both in the attention sense as the "adds an extra click" sense. We already have the "sent" folder for an overview of what has been sent.

It'd be more logical to display them at the bottom of the main window, either as part of an (interactive) statusbar or just above of the statusbar - and disappear automatically (like Growl notifications).
The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a
result, we feel that this bug shouldn't stand in the way of all the other good
work getting into the hands of users sooner rather than later. Therefore we are
retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242
for more details. The 3.1 release is expected to be a quick release soon after
Thunderbird 3.
Flags: blocking-thunderbird3.1+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Whiteboard: [b3ux]delight [no l10n impact] → [delight]
Target Milestone: Thunderbird 3.0b4 → ---
Re comment #115 ... whatever works, but the next time I bother to upgrade Thunderbird and/or Mozilla, will be when they have this bug fixed, and decent support for Reply to List.
Gless, I agree. Not many folks will wait for seven years to have the bug fixed to remain loyal to Thunderbird when other mail clients have improved a lot during this period.
Come on... PLEASE fix this for 3.0.  There have been over THIRTY duplicate bugs created.  If anything says this is annoying, this fact does.  I'm actively looking for a new offline IMAP email client and will switch away from Thunderbird as soon as I find a good one... I may even move back to Outlook.
Come on... PLEASE fix this for 3.0.  There have been over THIRTY duplicate bugs created.  If anything says this is annoying, this fact does.  I'm actively looking for a new offline IMAP email client now.  This can't be tolerated.
(In reply to comment #119)
> This can't be tolerated.

Excuse me?

Their intent to fix this has been made clear. It has been around for so long, loads of people have been happily using Thunderbird for all this time and now it's unacceptable to wait for it to be fixed right after the 3.0 release?
Yes, this bug annoys me as hell every now and again and yes, I would have hoped to see it fixed way back, but a remark as this is completely unfair and honestly quite rude to the developers who have worked and are working on Thunderbird. Yes, development is slow, but what have _you_ done to improve this? If it mattered so much to you, why didn't you fix it or why didn't you get someone to fix it for you in whatever way? Don't forget that you are using the program _for_free_ and there's no one stopping you from using something else. Instead of putting the people who at least keep improving the program down, try to motivate them instead. This is not helping one bit.
(In reply to comment #120)

Sorry for the bugspam, but the condescending attitude calls for a reply.

> to see it fixed way back, but a remark as this is completely unfair and
> honestly quite rude to the developers who have worked and are working on
> Thunderbird. Yes, development is slow, but what have _you_ done to improve
> this? 

He's doing QA work. A bit rudely, perhaps, but still. He's most probably reported some confirmed bugs, too. Or at least, he might have and you probably haven't checked.

> If it mattered so much to you, why didn't you fix it or why didn't you
> get someone to fix it for you in whatever way? 

That's a completely outrageous statement. What, you expect people to become TB devels? Some of us have to work for a living, support families etc - and there are a zillion software projects which need attention besides TB. Plus, even for someone who might consider doing TB coding - it's extremely difficult to make heads from tails, there practically no documentation of the core code, there's not much in the way of training, the code is bloated ugly and crufty in many places, etc. etc. (I do extension development btw)

> Don't forget that you are using
> the program _for_free_ and there's no one stopping you from using something
> else.

Google bankrolled MoCo (even though they jettisoned Thunderbird), so in the grand scheme of things all of this should already have been payed for anyway.

> Instead of putting the people who at least keep improving the program
> down, try to motivate them instead. This is not helping one bit.

This last sentence I think we can all agree with and I think you would have done well to limit your comment to mostly that.
(In reply to comment #113)
> It'd be more logical to display them at the bottom of the main window, either
> as part of an (interactive) statusbar or just above of the statusbar - and
> disappear automatically (like Growl notifications).

Additionally, these status messages could just be accumulated in a status log, which you could open in a separate window (like Outlook Express used to do, which looks like the Firefox DL window), or even BETTER, in a tab on the main window. That is one thing I like more about Google Chrome than FF, is that everything happens in a tab. 

This issue of the modal dialogs has got to be fixed, it is the #1 most annoying thing I find about TB2.
They don't even have to make the status log visible in Thunderbird.  Just have a config option that logs all these messages to the status log file.  I don't think it would be that challenging to couple that with an addon that puts an icon onto the status bar when connections cannot be established to one or more servers.

Everything else is just gravy.  But there's no way it could make 3.0 anyway.  The code freeze has already happened for 3.0.  Sigh.
Hello, 
+1 on this bug (still on rc1) : especially annoying when you've got 10 pop accounts !

I had to disable check at startup for all accounts so that I can work at once with TB even if not connected to a network.

Michel
Count me in, a solution is overdue already.  At least a temporary solution should exist in the upcoming release.
+1
I'm looking forward to it...
Please stop adding your comments saying you want this bug fixed.  It may be surprising, but this detracts from actually getting it fixed.  We want it fixed too, it's just not as easy at it might appear.
While I can sympathize with developers for volunteering their time freely for a mail client we love so much, it is probably about time for developers to let the users know true status. This bug was reported more than _seven_ years ago. Either no one is looking seriously any more or no one has a clue how to fix it. I hate to move to some other mail client because I have lived with TB all my life. But now, it has become almost unusable. Like most of us, I have several accounts to maintain. Every now and then some mail server has some temporary problem triggering my thunderbird to virtually freeze in my absence. Is it really so hard to just put a warning message without requiring user to click OK button for TB to continue with the normal program flow? After all, the user does not have to make any critical choice, and has to click OK, the only choice s/he gets.
I totally agree, this is the simplest bug to fix and the most annoying. Yet it has taken way too many years.  Someone, the program manager perhaps should put this on high priority.
[developers working on this, skip this comment]

Vako:
If it's so simple, and your statement sounds like you understand the issue well, then a patch would be much appreciated by everyone. Would help much to satisfy everyone. On the other hand, if you can't add anything here that helps actually fixing the bug, please refrain from commenting, as every developer working on this bug needs to read all 133 comments searching for clues how to fix it. This is not fun and usually the reason why bugs with over 100 comments rarely get fixed at all.

Please, please, please take this into account and read comment #131 from the Thunderbird project leader (!) before posting any more comment.
I understand the concern and apologize for being 'demanding'.  However, if they are looking for details, feedback, testing, comments, help, etc.  Please let us know how we can provide information to make their work easier and faster.
I am sure all here would love to provide information to the developers.
If I have to click on "OK" on this pointless dialog box for a 120th time I'm going to scream.
only 120times?  good for ya! ;)
Just download TB ver3 and I think they resolved this issue in it, haven't seen it for couple of weeks now.
I beg to differ.
Ok, I fixed the bug (or rather call it extreme annoyance).

Of course, it's not in the official build. I'm not a Mozilla developer, and this is just a crude hack in the code.

If anyone interested in hosting this fix (source + windows binaries), please contact me: shula dot amokshim at: gmx dot com

See my blog for details:
logli.blogli.co.il/archives/28
We'd be much more interested in the patch than in builds with unknown code - and actually, IIRC, the license forces you to publish the patch if you publish the builds.
That's funny since he's just removing one line of code... the code that calls the dialog box when it can't connect.  I think that would be pretty easy for them patch if they wanted to.
Well, TB3 has an improvement in handling this.  Instead of incessantly prompting a user for the password, it asks if the user would like to Retry, Enter New Password, or Cancel.  Perhaps not perfect, but leaps and bounds better than previously.
While this indeed rotten user-experience, if this were the last bug standing in 3.1, we wouldn't hold the release for it, because 3.1 is primarily about being a release that we can offer to Tb2 users as a Prompted Major Update, and this isn't a regression.  As a result, marking blocking-, but status: wanted+.
blocking-thunderbird3.1: --- → -
status-thunderbird3.1: --- → wanted
Flags: blocking-thunderbird3.1+
sorry, tomer, i don't know how to produce a valid "patch" file.

i even accidentally deleted my own patched CPP file, and i can't but the fix is trivial.

here's my change in file \mailnews\base\src\nsMsgMailSession.cpp 
around line 243 (in one of the older versions)


	wwatch->GetNewPrompter(0, getter_AddRefs(dialog));
  }
  //if (dialog) {
  //	nsAutoString hostStr;
  //	CopyASCIItoUTF16("this sux2", hostStr);
  //	// orig: 
  //	// return dialog->Alert(nsnull, PromiseFlatString(aMessage).get());
  //	// shula:
  //	return dialog->Alert(nsnull, hostStr.get());
  //
  //}

  return NS_OK;


in the latest version, it seems to be here (lines 277, 278) :
277   //if (dialog)
278   //   return dialog->Alert(nsnull, PromiseFlatString(aMessage).get());
279 
280   return NS_OK;


see my post for a more detailed explanation
http://logli.blogli.co.il/archives/28
(In reply to comment #144)
> sorry, tomer, i don't know how to produce a valid "patch" file.
> 
> i even accidentally deleted my own patched CPP file, and i can't but the fix is
> trivial.

It's documented at https://developer.mozilla.org/en/Mercurial_FAQ. Once you have a patch you need to follow the following https://developer.mozilla.org/en/comm-central#Requirements ground rules.
plus this patch is totally unacceptable for landing - we need a way to present the error to the user; just ignoring it as this patch does is not acceptable for the product, though I'm sure the dialog is annoying enough for some users that they are willing to live without knowing about any errors.
Can't we at least have a setting in about:config that would disable this error?  So the code above would be:
if (dialog && disablecan'tconnectsetting != 1) {
}
The set that setting to 1 to disable this error message.  I would consider that an acceptable intermediate solution.
you've disabled all error messages, not just this one.
(In reply to comment #148)
> you've disabled all error messages, not just this one.

VERY GOOD!  
no modern multithreaded application should block the user from working, it's unaccepted. only fatal crash should be modal.

also, i agree that the user MUST be notified. i suggest e.g. using TB's built-in non-blocking email alerts!.
at least shuold be configurable via about-config settings.

look, i've tried to implement myself, but by i'm not a C++ developer, and i gave up, since i'm satisfied with what i achieved.
Can we turn this patch into a plug-in, to get it out to people who don't care about error messages?
I'd like to point out that in the current situation, the message is not getting to the user either.  Rather, when the message occurs, the program becomes completely unusable and must generally be crashed to recover.

I'm all for letting the user know about problems, but the current method, (crashing the program), seems like a poor way to go about that.
(In reply to comment #149)
> (In reply to comment #148)
> > you've disabled all error messages, not just this one.
> 
> VERY GOOD!  
> no modern multithreaded application should block the user from working, it's
> unaccepted. only fatal crash should be modal.
> 
> also, i agree that the user MUST be notified. i suggest e.g. using TB's
> built-in non-blocking email alerts!.

We're in total agreement - we haven't been able to get UI traction on doing non-blocking e-mail alerts, and I think that's a shame.
Can't the error messages be tunnelled through to the statusbar as an intermediate solution?

Is the UI decision the only thing blocking progress on this bug?
The UI decision is really only a small part of what's blocking progress here.  The much larger part is that fixing this requires refactoring a whole bunch of code that currently is structured to use a synchronous API to be asynchronous.  This is a very large amount of development work.
And there isn't even universal agreement amongst developers that this is a necessary or desirable architecture.

I believe that it is, but at the same time, problems like this are driving thunderbird to be increasingly unstable and increasingly less useful.  I'm dealing with about a crash or two a day at this point, most of which destroy the state directory and force me to either start all over or restore from backups.  I'm very close to looking for a new mail UI.

Users who can't use the program anymore, developers who would like the fix the problem but aren't allowed to.  That's a recipe for revolution.

I don't know how to fix the political problems.  I'm not sure they can be fixed.  Typically, when there's a directional conflict of this magnitude in an open source or free software project, there's a code split and then both developers and users vote with their feet.
Crashes can be dealt with to ease the pain, but I see no crash report ids or bug number for a crash sprinkled in the comments that mention "I crash". Has anyone filed a bug for the crash(es)?
Speaking as one of the dozens of non-programmer end-users who have independently reported this 8-year-old bug (in my case, in June 2008), I would say that the program could be considered "crashed" every time one of these infernal dialogs pops up. I beg the Thunderbird community to address this issue as a priority.
It's not a "crash" in the sense of a core dump.  It's a "crash" in the sense that the only thing one can do at that point is kill it.  That's with respect to this bug.

Yes, I also have 3-4 actual core dump crashes a week also.  But they all seem to deal with similar issues - thunderbird getting confused about which servers are available, (or not), or which network interfaces or routing are available, (or not).
First, let me state that the problem here is not related to "allowing" and "not allowing" of things, but rather that we know of no developers with the appropriate expertise who feel that they have the time to do this work in the immediate future.  If anyone here knows of such a person, please ask them to send me email, and I'll help them figure out how to get this bug moving again.

With regard to the recent comments, I understand that there's a lot of frustration built up here, and I think it's entirely valid.  I myself find this bug a real irritant in day-to-day use.

That said, using Bugzilla to vent frustration actually makes it harder to get the work of fixing it done (and in the case of this bug, it's plenty hard already).  I would like to request that folks who wish to discuss non-technical aspects of this bug move that discussion to our support forum, at <http://getsatisfaction.com/mozilla_messaging/topics>.

Folks who do have specific _technical_ contributions to make, please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> before commenting again in this bug.

Thanks, and here's hoping we find someone to cause this bug to be fixed soon!
Attached patch Proposed fix — — Splinter Review 
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.
Attachment #437291 - Flags: ui-review?(clarkbw)
Attachment #437291 - Flags: review?(bienvenu)
So, for those users that don't have the new mail alerts turned on, they will no longer know when this error occurs?
(In reply to comment #163)
> So, for those users that don't have the new mail alerts turned on, they will no
> longer know when this error occurs?

No. I only said in a similar way to the new mail prompt. The new mail alert preference won't have any effect on the alerts we're talking about here.
Attachment #437291 - Flags: review?(bienvenu) → review+
Attachment #437291 - Flags: ui-review?(clarkbw) → ui-review+
Blocks: 558014
Checked in: http://hg.mozilla.org/comm-central/rev/359fc1dbd00e

I forgot to mention earlier that I can't currently think of an automated test for this, as we need to be running under UI, but we'd also need to detect the presence of the alert, and without hacking the alert service from mozmill, I don't think that would be easy to do. Therefore suggesting we have a litmus test for this.

This will be in today's nightlies (in a few hours time) and will be included in Thunderbird 3.1 beta 2.

Moving to the Thunderbird component as the way we fixed this means that SeaMonkey needs to do its own version of the fix. I've raised bug 558014 to cover that fix.

Please raise any follow-up issues in separate bugs and not here.
No longer blocks: 94228
Status: NEW → RESOLVED
Closed: 23 years ago → 14 years ago
status-thunderbird3.1: wanted → beta2-fixed
Component: Backend → Mail Window Front End
No longer depends on: 476696
Flags: in-litmus?
Product: MailNews Core → Thunderbird
QA Contact: backend → front-end
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1b2
TB 6.0.2 still has the annoying, focus stealing, MODAL "Confirm  There was an error saving the message to Drafts.  Retry?" dialog when a connection is lost while composing mail. This bug is not resolved, not fixed, still an infuriating UI error.

 As mentioned before, Modal dialog boxes are completely antithetic to tolerable UI design, especially when alerting users to something they can't do anything about.  Can save the message to Drafts?  BFD.  Try again silently in the background.  Keep trying.  My other options is "cancel" which stops the attempt, so what do I care if it tries in the background without annoying me or not?  

This dialog is particularly intolerable as it interrupts the flow of composing a message - it seems to wait for a pause in data entry to test, then throws the modal on fail, which I have to dismiss before I can get back to my thoughts, which are almost certainly lost as I stab my mouse in blind fury to dismiss this pointless dialog.

Do not steal focus, never ever throw a modal dialog box unless immediate user intervention is necessary to select from two or more options where each will result in different but irreparable data loss.
Yes, I think they will fix it on version 276.22 ;)
I gave-up on this. Some people think that because it's free we shouldn't be bug-reporting, yet I find it ridiculous that new versions are popping-up every week and these annoyances are not even on their plate!
The most annoying of them all is: "This folder is being processed.  Please wait until processing is complete to get messages".  As you said, just do it in the background, we don't have to know that!

But I love TB!
I hate to say it, but I'm getting the impression that these bugs are quite deliberate.

Motivation: to make Firefox (and other softwares, unfortunately Firefox is not the only one there) suck as much as Windows, in order to attract new customers from the Windows world.

The funny thing is that nobody on these bugs likes to admit this. However, it is easy to spot, because maintainers tend to implicate themselves into contradictions easily. When a number of people chime in saying that the behaviour sucks, maintainers say it's difficult to fix (or the single maintainer of this area "does not have time right now"). When then somebody rises up to the task and posts a patch, it's suddenly "users actually prefer the current behaviour". Also, there's often quite a bit of misdirection going on about the exact technical area in which the bug resides.

IMHO, Firefox (and other software) should really try to stay true to themselves, and cater to the users who joined because they hate Windows' way of doing things, rather than trying to attract hypothetical Windows users by becoming like Internet Explorer. If Firefox becomes just another Internet Explorer clone, what's the point of using Firefox rather than just staying with Internet Explorer?

Also, this is marked fixed. WTF?
Whilst I can understand your frustrations, please be aware that bugzilla is for technical work, and we want it to be an enjoyable place to work. Comments especially like Alain's in comment 170 only serve to discourage developers and volunteers from fixing a bug.

Please read the etiquette before posting again: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

If you feel the need to advocate or vent, <http://getsatisfaction.com/mozilla_messaging/topics/> is a more suitable place for that.

Also please do not comment on closed bugs - especially when the issues are commenting about are separate bugs (this issue was about a mail server timeout) your issues are separate (and in this case only related by the fact they are modal dialogs).

The relevant bugs have been commented about are bug 321783 for the saving drafts issue, and bug 101584 covers the folder being processed message.
Status: RESOLVED → VERIFIED
How about we schedule a task every couple of years where we go over all the unfixed bugs which are older than 5 years, and have loads of lively comments?

Then fix those bugs by high priority.

Btw, "unfixed" should include "RESOLVED WONTFIX", "VERIFIED FIXED", and similar "fixed, but not really" labels obviously.

And free beer for all the commenters if a bug reaches ten years old, hehe ...
Mark, we ask you to solve this annoying modal problem for more than TEN YEARS. I'm a developer, I know how it works. There are only 3 or 4 recurring alert windows. Don't tell me it's big job to offer an option to disallow these alerts. At this stage, I agree with Alain, if you don't do it, it's because you don't want to do it.
But I really blame the team for such decision as my Thunderbird regularly breaks my thinking for years just to tell me useless complaints. It's not even questions. It doesn't ask me any action. It just tells me the same things every few hours days after days, for YEARS.
I don't know who is responsible for such stupid and unproductive decisions but I blame this manager for beeing responsible for a lot of my headache and brain pain during the last 10 years. 
PLEASE give us a line in about:config to DISABLE these 2 or 3 annoying modal alerts. 
THANKS.
I agree with slambert - I've collected screen grabs of idiotic/pointless/annoying modal dialogs I have to deal with on regular basis.  There is no excuse at all for these modal dialogs, no plausible justification, no reason, ever.  

Errors the user should never ever be notified of, let alone via a focus stealing modal dialog box:

Alert: The operation failed because an other ...

Confirm: There was an error saving the message to Drafts.  Retry?

Save Draft Error: Unable to save your message as draft.

Coinfirm: there was an error saving the message to Sent. Retry?

Alert: the folder 'Blah' cannot be compacted because...


Alerts the program should be smart enough not to display under circumstances such as a dropped connection or when the computer is connected to an un-authenticated network, such as a hotel or airport connection pre-authentication:


Send Message Error: Sending of message failed... (duh, I'm not authenticated, just shut up and wait like a good, obedient program.)

Add Security Exception: ...wrong site... (duh, haven't authenticated, don't generate 500 of these stupid dialogs stacked when my 1 hour hotel internet expires)
Exactly. Or at least give us an option to disable those messages, like other programs do - a checkbox for "Do not show this again"
dudes, 
1. this bug had a patch, it shipped, and bug is closed.
2. perhaps do a little effort into looking at open bugs [1] and you probably easily find  a bug which matches what you want, like bug 493043 (found in 2 minutes)
3. and if you don't, then please file a new bug.
But please stop spamming this one.
And please don't comment in other bugs unless you are contributing to fixing it. TIA

[1] https://bugzilla.mozilla.org/buglist.cgi?list_id=2284835;field0-0-0=short_desc;value0-0-0=dialog%20error;field0-0-1=keywords;type1-0-1=allwordssubstr;product=MailNews%20Core;product=Thunderbird;field1-0-1=short_desc;type1-0-0=substring;type0-0-0=anywordssubstr;type0-0-1=substring;resolution=---;classification=Client%20Software;classification=Components;query_format=advanced;value1-0-0=connect;field1-0-0=short_desc
Thanks glad to hear that.  But will this fix be committed in final code?  I'm using TB 10.0 and still don't see the fix.  I will check other posts as well.
(In reply to Vako from comment #177)
> Thanks glad to hear that.  But will this fix be committed in final code? 
> I'm using TB 10.0 and still don't see the fix.  I will check other posts as
> well.

target milestone indicates when patch for _this_ bug report checked in. version 3.1
closing this bug report doesn't necessarily mean the problem (or a problem) is totally fixed. 
remaining bits get handled in follow up bugs. like  bug 493043.
Whiteboard: [delight] → [FIXED: COMMENT 166]
Wayne, how am I supposed to use this patch in my Ubuntu?  Can you please include it in the normal releases?

I added the PPA in the repositeries so I could upgarde to Thunderbird 10. This fix is NOT included into Thundebird 10.

More, the config parameter prompts.tab_modal.enabled is not available in this version ( https://developer.mozilla.org/en/Using_tab-modal_prompts )

You gyus love these modal alerts too much and you do everything you can to force them and to make us suffer them. Is that an insider job to support MS OE, or what???

So I understand you don't like complaints and messages here but the web and your bugzilla is full of demands about this functionality for YEARS. Before you send away all of us , can you please give us a REAL solution we can use?

Thanks!
Folks, please, please, please do not comment on closed bugs.

This bug fixed a very specific instance of modal dialogs in Thunderbird. As I commented in comment 171, there are other bugs about modal dialogs than just this one.

If you think this issue still exists in the latest version of Thunderbird (currently 10.0.1), please file a new bug with exact steps to repeat, and preferably a screenshot or full wording of the dialog you are seeing. We have fixed something in this bug, and we won't be re-opening it - that is our policy. New bugs get filed for new regressions/bugs.

If you have a different issue about a modal dialog in the latest version, please make sure there is a different bug filed on your issue with steps to repeat for it. We then have something to work on and to point people to 

Commenting on closed bugs is liable to get your comments ignored and then your issue won't be fixed.
Whiteboard: [FIXED: COMMENT 166] → [FIXED: COMMENT 166][Please do not comment on this bug!]
See Also: → 493043
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: