363666 - No messages show up in IMAP folder listings due to QUOTAROOT parsing problem

Status: RESOLVED INVALID

(Thunderbird :: Mail Window Front End, defect)

Description

[Chris Andrichak]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/418.9 (KHTML, like Gecko) Safari/419.3
Build Identifier: 2.0b1

Downloaded 2.0 beta 1. Ran it with same profile from 1.5.08. When it logs into my main IMAP account, after it reads the folder, All the messages in the list for that folder disappear - I am left with an empty folder. If I switch back to 1.5.0.8, everything works fine and all the messages show up.

This happens for all folders. For folders other than the in box, I can actually see it opening the folder and displaying the initial list of messages, and then all the messages just disappearing - poof.

Reproducible: Always

Comment 1

[Magnus Melin [:mkmelin]]

View > Messages is set to all?

Comment 2

[Chris Andrichak]

Yes, it is set to all by default. I have tried changing to other things, and then back to all but it does not fix the problem.

I also tried deleting my entire contents folder of IMAP folder listing cache files (the folder in my profile folder called ImapMail), and that did not help either.

Comment 3

[Chris Andrichak]

I just downloaded 2.0b2 and I am having the same problem. I went through the formal process (option-double-click start) of creating a new profile and added 1 IMAP account. logged in, and see an empty inbox which I know has 40+ messages in it. If i log in with 1.5.x, I see everything fine.

The cursos seems to stick at the BW watch in thunderbird, although I can do things no problem.

Error messages from the error console:

Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIIOService2.manageOfflineStatus]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///Users/chris/Desktop/Thunderbird.app/Contents/MacOS/components/offlineStartup.js :: anonymous :: line 95"  data: no]
Source File: file:///Users/chris/Desktop/Thunderbird.app/Contents/MacOS/components/offlineStartup.js
Line: 95

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgAccountManager.defaultAccount]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: MigrateJunkMailSettings :: line 1748"  data: no]

I am running against a Merak Icewarp IMAP server.

Comment 4

[Magnus Melin [:mkmelin]]

I think those js errors are unrelated. 

Are you sure the messages are downloaded? What you saw "initially" wasn't cache of the messages you already downloaded?
An imap protocol log may be helpful
<http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap>

Comment 5

[Chris Andrichak]

Attachment: imap protocol log

imap protocol log

noticed this error:
37691392[5e03fb0]: 22fec00:mail.grope.com:S-INBOX:SendData: 11 getquotaroot "INBOX"

37691392[5e03fb0]: ReadNextLine [stream=5e04698 nb=67 needmore=0]
37691392[5e03fb0]: 22fec00:mail.grope.com:S-INBOX:CreateNewLineFromSocket: * QUOTAROOT C:\Program Files\Merak\mail\grope.com\chris\inbox\ ""

37691392[5e03fb0]: 22fec00:mail.grope.com:S-INBOX:PARSER:Internal Syntax Error: %s:: no atom characters found
37691392[5e03fb0]: 22fec00:mail.grope.com:S-INBOX:PARSER:Internal Syntax Error on line: %s: * QUOTAROOT C:\Program Files\Merak\mail\grope.com\chris\inbox\ ""

37691392[5e03fb0]: 22fec00:mail.grope.com:S-INBOX:SendData: 12 UID fetch 1:* (FLAGS)

Comment 6

[Chris Andrichak]

The previous error with the QUOTAROOT response is causing TBird to logout before the server sends back the message listing:

37691392[5e03fb0]: 22fec00:mail.grope.com:NA:SendData: 13 logout

dunno if the response is valid or not. Will have to look it up.

Comment 7

[David :Bienvenu]

Did this work with 1.5.0.8? We might have tightened up the parsing of the quota response in 2.0

Comment 8

[Chris Andrichak]

Yes, no problems pre-2.0.

* QUOTAROOT C:\Program Files\Merak\mail\grope.com\chris\inbox\ ""

Seems like this is valid response to a getquotaroot request per RFC2087 (I'm way sketchy on BNF form though).

Comment 9

[David :Bienvenu]

looks to me like this code has gone back and forth and back and forth:

https://bugzilla.mozilla.org/show_bug.cgi?id=274546 and this checkin http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsImapServerResponseParser.cpp&branch=&root=/cvsroot&subdir=mozilla/mailnews/imap/src&command=DIFF_FRAMESET&rev1=1.136&rev2=1.137

I need to look at the rfc - it looks to me like we're just eating all the tokens...

Comment 10

[David :Bienvenu]

cc'ing our parser expert - on the 2.0 branch, we're still doing what I did in https://bugzilla.mozilla.org/show_bug.cgi?id=274546 - I don't think we can skip to crlf like we are doing on the trunk, because of bug 274546

Comment 11

[David :Bienvenu]

or does perhaps skip to crlf do the right thing with string literals now?

Comment 12

[Hans-Andreas Engel]

Attachment: Properly skip QUOTAROOT response

David, as you have found out in Comment 9,
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsImapServerResponseParser.cpp&branch=&root=/cvsroot&subdir=mozilla/mailnews/imap/src&command=DIFF_FRAMESET&rev1=1.136&rev2=1.137
the old code for QUOTAROOT has sneaked back in... 

The blame is on me: in Bug 327754 I first submitted a reasonable patch (id=212417) and then somehow fell back to the old version (id=212418).

Anyway, |skip_to_CRLF()| does not do the right thing there---so Bug 274546 appears again.  I extracted the part of the "good" patch (id=212417) and have attached it (but have not tested it again).

Comment 13

[David :Bienvenu]

Comment on attachment 252997 [details] [diff] [review]
Properly skip QUOTAROOT response

ah, thx so much! That looks like the right thing to do.  I'll try it out today.

Comment 14

[David :Bienvenu]

I've landed this on the trunk and branch, to get feedback as quickly as we can. It worked with the four imap servers I have access to, that support quota ...Chris, can you try out a nightly 2.0 build - the fix will be in tomorrow's build.

Comment 15

[Chris Andrichak]

version 2 beta 2 (20070128) from nightly/latest-mozilla1.8/ - still having the same problem. Same error messages in the imap protocol log.

I built a trunk version last night and had the same problem, and verified it had the patch in it.

I'm now wondering if the parser is having trouble with the windows path? The backslashes are not atoms and are confusing it - (they should be escaped/double-backslashes)?

Could be that this is pushing bug 322863 & patch beyond it's limits?

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsIMAPGenericParser.cpp&branch=&root=/cvsroot&subdir=mozilla/mailnews/imap/src&command=DIFF_FRAMESET&rev1=1.50&rev2=1.51

Comment 16

[David :Bienvenu]

right, the \ need to be escaped:

atom            ::= 1*ATOM_CHAR

ATOM_CHAR       ::= <any CHAR except atom_specials>

atom_specials   ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
                    quoted_specials

quoted_specials ::= <"> / "\"

Comment 17

[David :Bienvenu]

any chance of contacting the Merak Icewarp IMAP server folks? I think they're returning invalid protocol...

Comment 18

[Chris Andrichak]

I've contacted them. They're pretty responsive...

Comment 19

[Chris Andrichak]

It's a problem in the 8.5.x versions of their server, which we are running. They've apparently fixed it in the latest 8.9.x versions. So I guess this would be their problem. Unfortunately we now have to either shell out for the upgrade or ... :-(