Closed Bug 67799 Opened 22 years ago Closed 22 years ago
Hitting 'Stop' & then redownloading messages results in duplicates
From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (WinNT; I) BuildID: 20010201 When retrieving mail messages after stopping the process midway ,all the messages are downloaded again including the ones which were downloaded previously. Reproducible: Always Steps to Reproduce: 1.Bring up the browser window 2.Open a new mail window 3.Compose a few messages ( say 5) and send it to an existing account by pressing the send button 4.Wait for some time and retrieve the messages by pressing the Get msg button 5.When the process of downloading the message is going on , interrupt it by pressing the stop button (say after the 2 message is downloaded,it should be noted that all the messages should not be downloaded completely) 6.now press the Get msg button again to resume the retrieval of the messages Actual Results: The messages downloaded earlier are downloaded again from the server. that is;all the 5 messages are downloaded again. Expected Results: The messages downloaded once should not be downloaded again, only the remaining messages should be dowmnloaded.that is; in this specific example only the remaining 3 messages should be downloaded.
This was once bug 26770, a nsbeta2+ bug (marked fixed June last year.)
this is a pop bug. re-assign to naving, who is our jefft-bug-owner now.
Assignee: sspitzer → naving
Component: Mail Window Front End → Networking - POP
change qa conact, cc esther
QA Contact: esther → sheelar
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: When retrieving messages after stopping midway all the msgs are downloaded again → Hitting 'Stop' & then redownloading messages results in duplicates
Confirmed Platform:PC OS: Linux 2.2.16 Mozilla Build: 2001021408 Marking NEW.
*** Bug 69244 has been marked as a duplicate of this bug. ***
uping severity and nominating this for nsbeta1. When users are downloading messages and if messages are huge because of attachments or what ever I see that they would stop downloading very often and this can result with lot of duplicate messages in the inbox. This is not just one message that is duplicated but it could be after downloading 20 messages and hitting stop on the 21st message and redownloading resulting in bringing down those 20 messages back again. I would like to see this fixed.
Severity: normal → major
The code is in place to handle this situation. I'll have to invesigate why it doesn't work.
Priority: -- → P2
Target Milestone: --- → mozilla0.9
I have not been able to reproduce this bug on win 2001030904 and linux 2001030913. On the contrary, I found out that if you do GetMsg(), Stop and then again GetMsg(), you lose a message. My guess is that the number of messages that you may end up losing will depend upon the number of times you hit Stop. Filed bug 71666 to cover this issue.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
The above is true for mac 2001-03-09-11
I have seen this problem but now that it has miraculously disappeared. I tried to reproduce with the recent builds and was unable to reproduce.Marking this as verified will reopen if this occurs again.
Status: RESOLVED → VERIFIED
sheela have you verified this when we don't leave messages on server( ) I guess you will get duplicates. Reopening.....
Reopening this bug.....
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
cc server experts jgmyers, max I have a fix for this bug that works when all the messages are <= 50kb. If all messages are > 500kb the fix does not work. The "QUIT" command is needed to update the server state if we do not leave messages on the server. The QUIT update the server state and removes all the message marked deleted which in our case would be messages downloaded successfully. I want to know how would server behave, while it is writing the message data to the client and it receives the quit command in the middle ?.
You really should be using the UIDL command of POP for this. Remember the UIDLs of messages you have downloaded successfully in a local on-disk per-POP-server database. On a reconnect, if you see a UIDL on the server that is in your local database, delete the message without downloading it. If, on the other hand, a UIDL in your local database is not in the server then remove it from the local database.
The problem is that the exisiting code does UIDL only when we leave messages on the server. The scenario that I mentioned is also a bug in 4x.
A good fix would have the client use UIDL regardless of the "leave mail on server" setting. Aside from the decision for when to delete the message from the server, the logic should be the same in either case. To answer the question being asked: sending the QUIT command while the server is still sending the message is technically pipelining. The POP standard neither permits or prohibits pipelining. The POP extensions document provides a way for a POP server to advertise when it supports pipelining. Pipelining in the absense of that server advertisement is aggressive and may lead to interoperability problems. Some clients provide a user preference which controls whether or not the client pipelines. In any case, if you send the QUIT message while the server is writing the message and then close the connection before the server is done writing the message, almost all servers will notice the inability to write the message before they can notice the QUIT command. Thus, sending the QUIT will have no effect.
fix checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
I have to verify this bug not leaving messages on the server so disregard my comments from 2001-04-02 17:14 I see that linux on build 2001-04-04-14 resulted in duplicates. Have not checked on windows and mac will do so....
It works fine for me using today's debug build on linux. Please verify again.
verified on linux buildid-2001-04-19-08. Still need to verify this on mac &win98
verified on buildid: 2001042606 win98 buildid: 2001042605 linux
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.