Open Bug 340405 Opened 18 years ago Updated 2 years ago

Ask the user if he wants to wait further or would like to cancel if server timeout occured

Categories

(MailNews Core :: Networking: POP, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: bugzilla.mozilla.org-6h11, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [workaround: see comment #1])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Thunderbird 1.5.0.4 (20060516)

When getting mail, the process is canceled when the server didn't respond within timeout period. My suggestion is to ask the user if he wants to wait further, like in Outlook Express.

Reproducible: Sometimes

Steps to Reproduce:
1. Get mail from a slow server or via a slow connection
Actual Results:  
Timeout message pops up, process is canceled.

Expected Results:  
Give the user the possibility to wait longer.
A workaround, not a fix:
There is already a pref in SeaMonkey's about:config or Thunderbird's Config Editor, viz. mailnews.tcptimeout (in seconds); it is documented at http://kb.mozillazine.org/Mail_and_news_settings#Mailnews..2A and http://kb.mozillazine.org/Modify_Thunderbird_settings -- increase the value if you often get timeouts.
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [workaround: see comment #1]
Blocks: 423488
The Options/Preferences UI was removed from Tb 3 prior to Beta 1 and the default timeout bumped from 60 to 100 seconds.

In the context of this RFE, a smart action would ask "Do You want to Retry" since "Wait" is not going to restart a new connection attempt.

The smart prompt would offer Retry now or Retry Later choices.
I would like to prefer even retry in background instead always complain it cannot connect to server. So in case it fails just show some exclamation mark in status bar for example but keep trying.
(In reply to comment #3)
> I would like to prefer even retry in background instead always complain it
> cannot connect to server. So in case it fails just show some exclamation mark
> in status bar for example but keep trying.

That would be equivalent to never timing out (setting the timeout delay to infinity). I don't think it would be a good idea -- connection dropouts do happen, you know.
(In reply to comment #4)
> (In reply to comment #3)
> > I would like to prefer even retry in background instead always complain it
> > cannot connect to server. 
> 
> That would be equivalent to never timing out (setting the timeout delay to
> infinity). I don't think it would be a good idea -- connection dropouts do
> happen, you know.

No it would be more like an auto-reset and retry from my interpretation of Comment #3.

I CC'd Bryan Clark for a UX opinion since this effects His work.
(In reply to comment #2)
> In the context of this RFE, a smart action would ask "Do You want to Retry"
> since "Wait" is not going to restart a new connection attempt.

I thought the timeouts I experienced were with an established TCP connection, without data being sent back to the client, but I may be mistaken.

Unfortunately, I cannot reproduce and investigate it since the provider I experienced timeouts with ceased to exist.
(In reply to comment #6)
> (In reply to comment #2)
> > In the context of this RFE, a smart action would ask "Do You want to Retry"
> > since "Wait" is not going to restart a new connection attempt.
> 
> I thought the timeouts I experienced were with an established TCP connection,
> without data being sent back to the client, but I may be mistaken.
> 
> Unfortunately, I cannot reproduce and investigate it since the provider I
> experienced timeouts with ceased to exist.

When the server connection attempt timed out, that terminated communication with the server. That is why "Wait" is not a useful choice. A new connection has to be attempted. How the client handles notification to the user is what I understood You to be asking to be improved.
I'm not sure what the best algorithm is going to be to solve, but here is what I believe our experience should contain. 

The user almost always wants the connection to restart automatically.  Assuming we have something like the Activity Manager running we should be able to show connections being restarting or auto-retrying after failing.  Giving people insight into the auto-rety policy should allow them to be able to cancel retrying if they feel the need. We want to avoid forcing people micro manage the connection to the server.  Checking for mail and connecting to the server is one of the mail clients main jobs, we shouldn't be failing at that and asking the user what to do next; just keep retrying until it works.

If there is a way to detect the need for an increased timeout, then perhaps we should just do that automatically on the retry.  Or if increasing the timeout a small amount isn't harmful then perhaps that should be the standard policy?  I'm not really sure how to answer that.

Essentially we can't ask the user for an effective timeout value, the person could only know to increase the value to a larger one.  If more timeout than before is really our only option then we should just do that without asking.

If it makes sense to wait on reconnecting for some reason then that's a reasonable thing to display to the user as well.  Whatever makes sense for reconnecting to the server in a smart fashion will make sense to people assuming we're upfront about it and keep retrying.  I wrote something similar to this a while ago: http://clarkbw.net/blog/2008/05/13/a-bit-of-a-communication-problem/
I had suggested adoption of the Dial-up MODEM Auto-Dialer model for use with Mail/News Password authentication cases to deal with ID/PW purging.  The same model could be applied here by setting a retry delay time and a max try setting. 
Then notify the User when the Auto-Retry process has maxed out.

A pretty message of '"X" attempts to connect to ______ server failed, indicating the server is not currently available. You can retry by clicking the Get Messages button.'

I think the Tb 3 default timeout of 100 seconds is OK. For this model a 15 second pause between retries may be adequate for any server resets cases. And the Max-Retry of 3 or 4 may be sufficient.  Auto bumping of the timeout time out   may not be needed, but keep on the RADAR as a backup option.  This should be somthing that can be tested with the Fake Server setup to decide on some default values.

Setting status to NEW on the basis of Comment #8
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Core → MailNews Core
QA Contact: networking.pop
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.