373272 - IMAP IDLE support broken/regression from 1.0.7 -> 1.1.x

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Zing]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1

I no longer get biff notification of new messages with seamonkey 1.1.x using IMAP IDLE.  Notifications using IMAP IDLE worked/works fine in seamonkey 1.0.x.

Reproducible: Always

Steps to Reproduce:
0. make sure IDLE support is turned on in client and turn off "check new messages every (blah) minutes"
1. connect to imap account that supports IDLE (fastmail.fm does)
2. you will get a biff notification after the first new email
3. check your new email.  great. go on with what you were doing
4. another new mail comes in...
5. biff notification never happens.

Actual Results:  
no notification of new mails after the first new email.

Expected Results:  
notification of new mails after the first new email

I have looked at protocol logs of a 1.0.x session and 1.1.x.  The main difference is 1.0.x is correctly sending back/setting up the IMAP IDLE command after it does it's work.  In 1.1.x, I only ever see one IMAP IDLE command.  1.1.x never re-setups the IDLE session... thus the imap server never sends imap status updates back to the client.

Comment 1

[Magnus Melin [:mkmelin]]

Could you attach the logs?

Comment 2

[Zing]

Attachment: imap protocol trace from seamonkey 1.0.x

Comment 3

[Zing]

Attachment: imap prot trace from seamonkey 1.1

Comment 4

[Zing]

I obscured a bit with xxx's in the above traces, but no lines should have been deleted.  The logs are from tests I did maybe a month ago? but I still see the same symptoms with seamonkey 1.1.1.

You can see in the seamonkey 1.1 trace the IDLE command never gets resent after I receive the initial new mail, while 1.0, I see a whole bunch.

Comment 5

[David :Bienvenu]

very odd - I tried this in TB 2.0, against the fastmail server, and we're going into IDLE after every url.

Comment 6

[Zing]

I installed and tried out TB 2 beta 2, and confirm the IDLE's are being sent.

Comment 7

[Zing]

I just tried out the SM 1.5a nightly:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070311 SeaMonkey/1.5a

and it too suffers the IDLE problem.  The trace is pretty much similar to the SM 1.1 trace... only 1 initial IDLE is sent and that's it after that.

Comment 8

[Zing]

I see the same symptoms with 1.1.2.

Comment 9

[Zing]

I have tracked this down further on Seamonkey 1.1.3 on my linux machine to the m_useIdle variable.  

In my testing, it is always line 738 in nsImapProtocol.cpp:
735    if (!shuttingDown)
736      (void) imapServer->GetUseIdle(&m_useIdle);
737    else
738      m_useIdle = PR_FALSE;

...and my reproduction recipe was missing the critical step...  what causes line 738 to be called is to close the mail client window.  For some reason (i hope someone knows here), this is what calls line 738.  m_useIdle gets set to false and in the ImapThreadMainLoop(), I have no chance of ever calling Idle() again.

In my testing, once m_useIdle gets set to false, nothing ever set m_useIdle back to true.

I really hope this helps clarify whats happening... I've almost hit my limit here.

Anything I can help with further debugging or testing, let me know please.

(all my debugging was done on linux, but I believe this is what's happening on windows also.)

Comment 10

[Wayne Mery (:wsmwk)]

would threadmanager checkin be too easy a target? :)

Comment 11

[Wayne Mery (:wsmwk)]

said that tongue in check but that was just dumb since we're talking branch.

Comment 12

[long]

I'm seeing the same thing with seamonkey 1.1.6 in fedora 8.  Shut the mail client window and IDLE support dies after that.

Comment 13

[Serge Gautherie (:sgautherie)]

Zing, long,
Could you narrow the regression timeframe ?

David,
Could test again, after the new informations ?

Comment 14

[Phil Ringnalda (:philor)]

So the Thunderbird STR is "open Addressbook, close main window, don't get mail"? That will not block Tb3a2 (or any other Tb alpha).

If I were looking for a regression range, I'd start on both sides of 2006-05-23, since the final landing for bug 312775 was what added the single caller of SetShuttingDown that would make you hit the shuttingDown path in nsImapProtocol.cpp.

Comment 15

[long]

Seamonkey 1.0.9 works fine, then it is broken in 1.1 alpha.

Comment 16

[Wayne Mery (:wsmwk)]

long, does SM 1.0.9 > 1.1 fit the 2006-05-23 time frame for bug 312775?

Comment 17

[long]

According to ftp.mozilla.org 1.0.9 was dropped on 5/10/2007 and 1.1a on 8/24/2006 so I think the answer is a no there (unless that bug wasn't fixed in 1.0.x)?

Comment 18

[Wayne Mery (:wsmwk)]

still see this with latest trunk?

Comment 19

[long]

If you're talking about SM 1.1.14 then yes, I still see this issue.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to comment #19)
> If you're talking about SM 1.1.14 then yes, I still see this issue.

long, trunk would be SM 2.x at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

Comment 21

[long]

Ok, just tried SM trunk and it appears the bug still exists there :-(

Comment 22

[Zing]

I just gave seamonkey-2.0b1pre.en-US.linux-i686.tar.bz2 a try and also verify the bug is still there.  I did the test with a clean ~/.mozilla profile.

Just to clarify, Comment #14 mentioned:
=========================================
So the Thunderbird STR is "open Addressbook, close main window, don't get
mail"? That will not block Tb3a2 (or any other Tb alpha).
=========================================

AFAICT, this bug doesn't affect thunderbird.

Comment 23

[Wayne Mery (:wsmwk)]

(In reply to comment #22)
> 
> AFAICT, this bug doesn't affect thunderbird.

wow, is that really possible?

see also idle bugs https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=idle&product=MailNews+Core&product=Thunderbird&resolution=---&chfieldto=Now

Comment 24

[Wayne Mery (:wsmwk)]

still see this problem?

(zing address is dead, which leaves only long. unless others are watching)

Comment 25

[long]

sorry, been out of town a while and still catching up.  I do plan on testing this when I get some time.

Comment 26

[long]

I do not seem to see this problem anymore in SM 2.11.  Thanks!

Comment 27

[Wayne Mery (:wsmwk)]

fantastic. Thanks long for testing.