Closed Bug 78809 Opened 19 years ago Closed 15 years ago
Offline:Offline copy of an imap message moved offline is lost when going back online
BuildID: 2001050304 on WinNT 4.0 While online, if you select a message(s) to be downloaded (by using Get Selected Messages or Get Flagged Messages method as with this current build (2001050304) the Sync Dialog window is not currently implemented) and then go offline. Move the message(s) you have downloaded to another folder. Go to that folder and try to read it and you will not be able to see the text body as it is blank. Reproducible: Always Steps to Reproduce: 1.Start Messenger 2.Log into your IMAP mail account (i am using move to trash can deletion model) 3. While online, select some messages (From your inbox) to be downloaded (must at least select 2 messages) by either method: a) - select some messages - Go to the menu and choose File->Offline->Get Selected messages b) - flag some messages - Go to the menu and choose File->Offline->Get Flagged messages 4. Go offline 5. Click on the downloaded messages (should be in italic) 6. You should be able to read them 7. Move those messages to another folder(s) 8. Go to the folder where you moved the message to 9. Click on that message that you just moved from your inbox Actual Results: You are not able to read it. If you go back online you are still not able to read it. The text body is blank whether you are in online or offline mode. Expected Results: You should be able to read it while in online or offline mode. You should be able to see the text body. Noticed some new additonal results? When I go back online, I also noticed that sometimes the message that was downloaded and moved to from inbox to another folder now looses it's 'italic mode'. And it behaves like a non-downloaded message. If i go back offline, I can no longer read the message and I get the "The body of this message has not been downloaded from the server for reading offline..." message. See bug 78520 http://bugzilla.mozilla.org/show_bug.cgi?id=78520 where I first mentioned the original problem in general terms.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
Summary: Offlie:Moving a downloaded message, while offline, from inbox to another folder results in not being able to read the message → Offline:Moving a downloaded message, while offline, from inbox to another folder results in not being able to read the message
moving to 0.9.2 but if you're able to get to this this before, then go for it.
Priority: P1 → P2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
I tried this out. Here's what I found. Moving a download message while offline doesn't copy the body. If you go online the message disappears from the folder but the next time you load the folder the message reappears and you can see the message. David is going to look into making the message not disappear when going online, which will make this bug less severe.
It turns out that 4.x had the same bug that Scott reported which is the following: If you do an offline playback synchronization and the folder that is selected has messages that were moved into it offline, the moved messages disappear until the next time you select the folder, or do another playback synchronization, or select the source folder of the move.
Status: NEW → ASSIGNED
Wanted to add quick note. In testing bug 83734, I noticed messages also disappearing when you try copying: -go offline -copy a message to another folder -click on that folder where you copied the message to -you can see the message -go online -message disappears from folder You have to click on another folder and then go back to 'see' the message that you copied.
OK, Gary and Scott, the move/copy messages disappearing behaviour you're seeing is a different bug and should be separated from this one. The disappearing messages is a 4.x bug as well which means I successfully ported the bug :-) . I think we probably want to fix both bugs but I'll leave that up to Scott to decide. Fixing this bug won't fix the disappearing messages bug at all - they're separate. Gary, can you file a new bug on the messages disappearing bug when you select the dest folder of the move/copy? Thanks!
*** Bug 84258 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta1+] → [nsbeta1+][PDT+]
moving to 0.9.3 for when David can look at this.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I have a fix at home to copy the offline message bodies when you move/copy a message while offline - I'll attach it tonight.
Whiteboard: [nsbeta1+] → [nsbeta1+] Fix in hand
cc'ing Seth and Navin for review. The one thing that's missing from this fix is that when you go back online, we forget the downloaded message in the dest folder but at least you can still read the message while offline.
I have already reviewed base part of the fix. r=naving on imap part of the fix.
fix checked into trunk.
Whiteboard: [nsbeta1+] Fix in hand → [nsbeta1+]
Commercial builds 2001-07-05-09-trunk/ win nt 4.0 2001-07-05-08-trunk/ linux 2.2, red hat 7.0 2001-07-05-08-trunk/ mac os 9.0.4 Verified On trunk only: That moving or copying a downloaded message (while offline) from its original folder to a new folder results in being able to read the message in the new folder while you are offline. Tried drag and drop method (Drag&Drop doesn't work in linux see bug 89438), Message|Move Mesage, Message|Copy message, and using move to/copy to when right clicking a message and they all work. You are able to read the message if it's moved/copied to another folder while offline. Note: when going online the message may 'dissapear' but will reappear if you visit the folder again (see bug 84249) and once you go back online, the message you moved while in offline mode will loose it's downloaded status once moved (think i have to file a new bug on that one). So if you go back offline and try to reread the message you moved/copied earlier, you won't be able to. leaving status as is.
oopps Removing Keyword Vtrunk since Verified on the trunk
yes, I knew (and said) that would happen (losing the offline message body when you went back online). It's very hard to fix that, and my guess would be that it didn't work in 4.x either.
Ok David, I won't file bug on a message loosing its downloaded status if you move it to another folder while offline.
adding nsenterprise keyword
since there was a new bug filed on the disappearing message bodies, what is left to fix in this bug?
Good question Scott. I think it is 'resolved;. David want me to change status to resolved? And next week I'll reverify on trunk.
what's left, is perhaps trying to fix it so that you don't lose the bodies when you go back online.
It looks like 84249 was filed for that.
84249 is about the msg hdr disappearing. I was talking about the offline message body disappearing when you go back online.
changing summary to reflect remaining bug, which is that when you move a message offline that has an offline body, we lose the destination msg offline body when you go back online. 4.x had this bug too, and there's no perfect way to fix this . The problem is that when we do the offline move, we create a dummy header and associate the offline body with it. When you go online and download the real header, we don't know that the real header corresponds to the dummy header. The only way I can think of to know this is to compare the message-id and a few other fields of the dummy header with the newly download header. I would recommend not fixing this for the next release - no one's ever complained about the 4.x behaviour.
Summary: Offline:Moving a downloaded message, while offline, from inbox to another folder results in not being able to read the message → Offline:Offline copy of an imap message moved offline is lost when going back online
sounds reasonable to me, especially if there were no complaints in 4.x about this..
same here, I'm going to move this down to nsenterprise status for re-triage. Definetly sounds like a good nsEnterprise- candidate.
Mail news triage meeting --> .9.5 (included eMojo reps)
moving to Future - this is hard to fix, and no one complained in 4.x
Target Milestone: mozilla0.9.5 → Future
Testing with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 doesn't show this problem at all. It seems that this bug was fixed anywere else in the last 3 years. => WFM
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.