80110 - Offline: Stop download, repeat sync/download doesn't go.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Backend, defect, P2)

Description

[laurel]

Using may08-09 commercial trunk build

After interrupting a sync/download (I tried IMAP account) via Stop, I most often
couldn't do a sync/download again on that account without closing mail session
first.

1.  Logged into IMAP account, INBOX selected for offline use.  (The accts I
tried had anywhere from 300-6000 messages in the inbox.) Inbox has a lot of
messages to download for offline.
2.  File|Offline|Download/Sync Now.  Checkmark Mail for download.  Left other
options (send unsent messages, go offline after sync complete) unchecked.  Click OK.
3.  Download/sync in progress, mail window status bar shows number of messages
being received. 
4.  Click Stop button.  Progress stops.
5.  Still online, repeat File|offline|Download/Sync Now.  Status bar progress
goes to Document Done.  No apparent activity, even after waiting awhile for it
to kick in.  (One time out of several tries I saw the download process start up
again.) All is okay if you close mail, open again then try a sync/download.

Comment 1

[David :Bienvenu]

do you mean, for example, that if you have  browser window open, you can close
the mail window, re-open it, and this problem goes away? If that's the case,
then it's a problem in the code that remembers that the window has been stopped,
or rather, a problem in not clearing that state on the subsequent "Download now".

Comment 2

[laurel]

Yes, of the several times I tried, some I exited the app and some I just closed
the mail window with a browser window open and tried the sync again and it
started up. 

Comment 3

[scottputterman]

marking nsbeta1+

Comment 4

[David :Bienvenu]

Laurel, could you try this again with today's build? It worked fine for me. I'm
wondering if perhaps you were offline after stopping the download and couldn't
tell because the offline indicater only very occasionally bore a resemblance to
reality, and the FE code was putting you offline immediately anyway. Seth
checked in a bunch of fixes for this last night. Also, did you have any
newsgroups configured for offline use?

Comment 5

[laurel]

Sure, I'll try it with today's builds. 
No I don't believe I had newsgroups configured for offline.

Comment 6

[grylchan]

tried 2001051504 on NT 4.0

Tried Laurel's steps to reproduce (w/newsgroup)

Newsgroup had only like 296 messages (all new) 
1  repeated her steps, started download
2. stopped it at 150/296.
3. resumed it
4. nothing happens (my mouse ptr is showing as hourglass)
5. says now downloading 4-288 articles?
6. repeat download/sync now again
7. now it works
8. starts from 150 and continues
9. if I stop it again and repeat laurel's steps
10. hangs says downloading articles 4-242?
11. continuing the same stop/start pattern results in nothing happening?
    Delay happens. It sometimes works. Very inconsistent
I know the status indicator doesn't always seem to accurately reflect the number
of messages actually downloaded. 

Repeating steps for my inbox w/160 mesgs.

1) Download sync now first time works.
2) stop it, repeat download sync now
   nothing happens
3) repeat again. downloading starts working.
4) stop
5) repeat dwnload steps, nothing happens.
6) stop
7) repeat. finishes last of downloading

Comment 7

[laurel]

I just tried it with may15 commercial build, mac OS 9.0.
Similar results to Gary's... Stop a download, do it again doesn't get going. If
I repeat again it starts up.  Seems it kicks in every other time.

Used on newly migrated imap profile, 600 messages, onlyn (single) Inbox selected
for download, no other folders or newsgroups selected.

Comment 8

[laurel]

Oh, and I did not elect to go offline after sync/download, was still online.

Comment 9

[David :Bienvenu]

I managed to recreate this once - I don't think it has to do with the stopped
state stored in nsMsgWindow.cpp - it may not have anything to do with offline
but rather with what happens when you stop a connection and then try to use the
same folder. I traced it to the point where we start downloading message bodies
for the imap folder and it bails out at that point.

Comment 10

[Marek Z. Jeziorek]

changing TM to 0.9.2 per PDT meeting (you can check the fix into 0.9.1 trunk
until Friday, 18/May/01 or after the 0.9.2 is open)

Comment 11

[David :Bienvenu]

OK, the problem here is that the folder has lots of messages to download. This
causes us to generate a FETCH command that is too long for the server. Our
server, unfortunately, seems to silently fail, and in fact, drop the connection!
If we go through the code that fetches messages during the select process, we
don't have this problem, which is why it works every other time.

Comment 12

[grylchan]

David, is this bug related to this bug? 
http://bugzilla.mozilla.org/show_bug.cgi?id=79033

Haven't tested the other bug as of yet.

Comment 13

[David :Bienvenu]

Thanks, Gary, they are very closely related. I was looking for that other bug
and couldn't find it. The difference is that the UW server is actually returning
an error message!

Comment 14

[David :Bienvenu]

Attachment: proposed fix

Comment 15

[David :Bienvenu]

Can I get a review, Navin? There are several fixes here - the most important one
is to not cache connections that have been disconnected. The other fixes are to
check if we've been cancelled when we're looping downloading headers or bodies,
to run a select to download all headers so we avoid sending an extremely long
protocol line, and to clear the m_downloadingFolderForOfflineUse flag in
nsImapMailFolder::SetUrlState because it seems that ::OnStopRunningUrl isn't
getting called in this case (I'm looking into that, but it's better to be safe
than sorry here).

Comment 16

[Scott MacGregor]

sr=mscott

Comment 17

[Navin Gupta]

r=naving

Comment 18

[scottputterman]

adding PDT+.  Please checkin as soon as possible.

Comment 19

[Keyser Sose]

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

Comment 20

[David :Bienvenu]

fix checked in.

Comment 21

[grylchan]

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

Comment 22

[grylchan]

David,
 Is your fix supposed to work for newsgroups also or just imap folders? 
I'm seeing very strange results with 2001-06-12-09-trunk/ on WinNT 4.0.

If it does apply to newsgroups, then bug 84069 may block me
from verifying this bug.

I'm also seeing weird things like stop button dissapearing (after 
stop/re-synching) and hourglass for the mouse arrow (after stop/re-synching) 
even though i have clicked the stop button. Thanks

Comment 23

[David :Bienvenu]

No, this fix doesn't involve newsgroups - it was only for imap.

Comment 24

[grylchan]

Using commercial builds
2001-06-14-09-trunk/ win nt 4.0
2001-06-13-08-trunk/ linux 2.2, red hat 7.0 (due to prob w/6-14 builds)
2001-06-14-08-trunk/ mac os 9.0.4

Following Laurel's steps to reproduce: [on all 3 OS's]
-I am able to Download & Sync, stop, Download & Sync, stop fine.
 There is no lag or period of inactivity. All messages get
 downloaded (i tried a test case of 500+ messages)
-For bug 79033, I used a U of Washington IMAP4rev1 v12.250 server,
 and tried downloading 6748 messages in my inbox. It worked
 fine. No error messages. It didn't quit, stall,etc..

marking as verified.