433006 - IMAP Idle doesn't recognize lost connection after S3 (sleep / standby)

Status: RESOLVED INVALID

(MailNews Core :: Networking: IMAP, defect)

Description

[Martin Seifert]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Build Identifier: Version 2.0.0.14 (20080505)

I'm using Thunderbird under Ubuntu Hardy Heron. I set up my IMAP account using the Idle feature and everything works fine except for resuming from Suspend to RAM.

After resuming from S3, Thunderbird doesn't report new mails anymore and even manually checking for new mails fails as well as downloading the content of already fetched headers. I have to quit Thunderbird and restart it to get it in a working state again.

Reproducible: Always

Steps to Reproduce:
1. Open Thunderbird with IMAP Idle enabled
2. Suspend to RAM
3. Resume
Actual Results:  
Thunderbird doesn't report new mails and even worse is unable to manually check for new mails.

Expected Results:  
Thunderbird reestablishes the connection to the IMAP server and reports new mails.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Similar situation is reported to Bug 425897 for Tb trunk on MS Win Vista.
Can "offline.autoDetect" to false be a workaround?

How long is the suspend time? If DHCP is used for client PC's IP address assignment, and if IP address assignment by DHCP expires during suspend, similar phenomenon can occur on Tb (AFAIR, already opened bug). Is this case? 

Anyway, get NSPR log and check real protocol level flow first.
See Bug 402793 Comment #1 for getting NSPR log.
Following will probably be required for your intial analysis.
> setenv NSPR_LOG_MODULES imap:5,nsSocketTransport:5,nsHostResolver:5

Comment 2

[Martin Seifert]

Attachment: NSPR log with S3 and resume

I'm using a DSL connection with dynamic IPs, so most likely the IP will change after every resume.

I tried to get the NSPR log, although I'm not sure if I did the right things. Ubuntu's shell doesn't feature setenv, so I used the following instead:

> export NSPR_LOG_FILE=NSPR-Log
> export NSPR_LOG_MODULES=imap:5,nsSocketTransport:5,nsHostResolver:5

After that I started Thunderbird which automatically connected to my IMAP account, went to S3, resumed from S3 and tried to manually check for new mails. After that I quit Thunderbird.

I hope there is no sensible information in this huge log, especially no passwords?

Comment 3

[Nikolay Shopik]

This could be same issue as Bug 468490

Comment 4

[David :Bienvenu]

no we don't reconnect if the server drops the connection while idle. But the normal check for new mail at the normal interval (I think the default is 10 minutes) will cause a reconnect, and then we'll go idle for as long as the server doesn't drop the connection.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to David :Bienvenu from comment #4)
> no we don't reconnect if the server drops the connection while idle. 

Gene, see we are working correctly, and this bug report (and bug 468490) are invalid?

Comment 6

[gene smith]

(In reply to Wayne Mery (:wsmwk) from comment #5)
> (In reply to David :Bienvenu from comment #4)
> > no we don't reconnect if the server drops the connection while idle. 
> 
> Gene, see we are working correctly, and this bug report (and bug 468490) are
> invalid?

No, I don't think these bugs are totally invalid. Here's why:

First, here's the full quote from 7 years ago. 

(In reply to David :Bienvenu from comment #4)
> no we don't reconnect if the server drops the connection while idle. But the
> normal check for new mail at the normal interval (I think the default is 10
> minutes) will cause a reconnect, and then we'll go idle for as long as the
> server doesn't drop the connection.

There is still an issue that some users assume that if they use IDLE (immediate notification) that they can just disable the poll for new mail every 10m. In that case, yes, if the connection is dropped new mail will not be notified. Or they may think they can have a really long poll interval like 60m just as a back up. In that case, new mail notification will be delayed for 60m if server (or tb) drops the connection.

Another problem is that tb doesn't really follow the RFC and redo idle at the 29m point. Many servers disconnect at the 30m point when the connection is inactive so the connection and IDLE are lost until the next poll interval occurs, if polling enabled.

Tb does have a 29m timeout but currently it doesn't redo IDLE. What it really does is cause any connection to appear "bad" if it has been inactive for at least 29m, so it is dropped and another connection is opened when an imap URL needs a connection to run. This behavior can also cause a connection that is using imap IDLE to be dropped since IDLE is not reestablished on the new connection.

A related problem is that the mailboxes (folders) that use IDLE are either Inbox and the most recent 4 visited folders (assuming 5 cached connections). It could be argued that the user should be able to configure specifically which folders use idle (provide immediate notification). This is helpful when server side filters to non-Inbox folders are setup. Folders with the right-click property "always check for new mail in this folder" could be high-priority candidates for permanent IDLE usage for immediate notification.

Anyhow, I have been working on the above issues surrounding the IDLE feature and have working code in place. I am still testing it and have not yet submitted a patch and complete documentation (other than the very preliminary patch in bug 468490 and what I just wrote here).

Comment 7

[Wayne Mery (:wsmwk)]

So this and bug 468490 can probably be duped to bug 1535969?
Perhaps also help bug 716461?

Comment 8

[gene smith]

Comment 0 of this bug seems mostly invalid now. New mail via IDLE stops on resume but you definitely don't have to restart to get new mail now. You will get the new mail on next biff (if enabled) or if you click get new mail.

I think the fix for bug 1535969 will help these bugs (the first 2) but I don't think they are dups. But I need to do some testing to know for sure.
Don't really see a relationship of these to bug 716461.

Comment 9

[gene smith]

I still agree with what I wrote in comment 8 about this bug being invalid. I use hibernate/sleep all the time and never see an issue with tb getting new mail.