Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010620 Sometimes dragging a message from the online imap folder to local folder makes the message disappear in imap folder (pref: mark message as delected is selected). selecting another folder and going back to the imap folder makes the "marked as deleted" message reappear. This is annoying because: A) the behavior is inconsistent. B) sometimes (always?) the curser jumps to & highlights a subject line but message body window shows another message.

reassign to karen since this is imap model

This is nothing for the delete mode, just the drag & drop behavior change from 6.1..... There is argument from bug 84905....

Based on bug 84905, resolving won't fix.

Verified.

I looked at bug 84905 and don't see what there makes this a wontfix. Reopening and waiting for an *explanation or fix*. The other bug is all about whether D&D should more or copy between folders. This bug is about that after dragging a msg (moving), the marked-as-deleted message *disappears* in the imap folder instead of getting a little red "x" on its icon.

Yes. I believe that this is also impacting from bug 84905: The reason is: we use D&D for COPY from IMAP to Local before, so from 4.x, you still see there is copy in IMAP server. But, since bug 84905 change the D&D behavior to MOVE, so it should MOVE msg from IMAP to Local....but, since for delete mode, it still trigger for putting "x" instead of clear msg on the UI from IMAP server. Updating the summary to make more sense for this problem: "IMAP mark as delete mode: Should remove/clear msgs from thread pane when D&D(Move) msgs from IMAP to Local?" I need to Cc Navin & Scott since this bug is impacting from bug 84905..... Clear all the keywords, Nominating nsbeta1.

I already confirmed with Scott & Navin -- this is works as design(current design). Marking as won't fix again.

Peter, Please don't compare D&D from Communicator 4.x for "mark as delete mode" since we change the D& D behavior for move. You can compare with 4.x by moving msgs from the menu bar for "mark as delete mode", then you will understand why we won't fix for this issue. Thanks for bringing this up. Marking as verified.

This behaviour is *highly inconsistent*, because: 1) Standard OS behaviour for a "move" operation is to first "copy" the message, and *then "delete"* the source file. So if user selectes *Mark as Deleted*, then the "deleting" step should do what the user is expecting based on his preference setting for a deletion operation in that folder - namely *MARK THE MESSAGE AS DELETED*!!! 2) sometimes dragging a message will mark as deleted, sometimes the message disappears. 3) when message disappears, it reapears (marked as deleted) after leaving and returning to the imap folder. 4) when message disappears, selection skips a message and selects the *second next* message instead of the one immediately below the moved message. All these points lead to a highly unsatisfying, frustrating and inconsitent user experience. *I STRONGLY suggest that this bug be fixed*. The only reasons you give for the wontfix are: "it's by design", and some vague statement about "moving msgs from the menu bar". None of these are a good reasons to not fix this inconsistent behaviour. I suggest the "design" be reconsidered. If the user wants deleted files to be marked as deleted, he will want this to also occur. BTW, I noticed that Karen is *marking AND verifying* her own bug resolutions - and she did it TWICE. This cannot be the correct way to do things - at LEAST not TWICE for a controversial bug. I request that another reviewer review this bug. Reopening for reconsideration.

I think there's some confusion about what this bug means. The behavior should be that the message gets copied to the new folder and the message gets marked as deleted in the original folder. If that's happening then this bug is a wontfix. If it's not happening then this bug is valid. It sounds like this bug is about the message disappearing and then coming back later when the folder is loaded again. The message shouldn't disappear, it should get marked as deleted.

Exactly: "the message gets copied to the new folder and the message gets marked as deleted in the original folder" - this is NOT happening, so this bug is valid. I just noticed that if a message does NOT have an attachment, it get marked as deleted after a move; but if it DOES have an attachment, it disapears after a D&D move operation. Rewording summary to be absolutely clear (as my original summary was)

Oh! I know your point now..... Since I couldn't reproduce this problem yesterday by moving the messages. (the moved messages work correctly with the "x" sign), so I thought that you were complaining about the moving behavior....After you specify for ATTACHMENT messages, then I can reproduce this problem now.... The problem is: After you moved the ATTACHMENT messages, it looks like it moves the attachment message right away, but after you select the Inbox again, the moved messages will display again with the "x" sign....don't know why it didn't mark the "x' sign right away for the ATTACHMENT messages....

It worksforme with attachments also. If you are changing the delete mode from "move to trash" to "mark as deleted" make sure you restart the client to take effect. There is already a bug about that.

I would be shocked if it has anything to do with whether the message has attachments or not. It's not impossible, but it's highly unlikely.

Adding nsbeta1 keyword to all regressions so they *get some love* and attention.

Using Mozilla 0.9.7 on RedHat Linux 7.2, it WFM, no matter whether a message has attachments or not. I use "mark as deleted mode" and when I D&D message from an IMAP folder to a local forder, the original message (in IMAP folder) is always correctly marked with a red X and never disappears. Anybody still seing this bug?

I just tested this (again) with 2001-01-14, winNT, IMAP, 230k file). After D&D the file to a local folder, after the download completes, the file *seems to disapear* from the IMAP folder. Only *after* selecting another folder and then reselecting the IMAP Inbox folder is the file displayed with a red "X". BTW. I just created a new profile yesterday - what a *major* pain in the A**. :( -> This is still broken.

Werid. Anybody see this on OS other than Windows?

wfm. I might have fixed this sometime back.

I just tested this (again) with 2001-08-03, win98, IMAP, 394k file. After D&D the file to a local folder, after the download completes, the file *seems to disapear* from the IMAP folder. Only *after* either selecting another folder and then reselecting the IMAP Inbox folder or clicking on "Get Msgs", is the file re-displayed in the Inbox with a red "X". PS. Please test this properly, I am tired of having to reopen this bug. -> This is still broken.

perhaps you could help us out by attaching a protocol log showing this happening? Here are the instructions: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

you test it properly or one of our QA's can do. it worksforme on winNT and win2k. don't reopen. I tried with single/multiple msgs in an imap folder.

if there is a problem, it could be that it is imap server dependent, which would explain why no one here can reproduce the problem (other than Karen - Karen, can you still reproduce this? what server were you testing against?). A protocol log showing this problem happening would be actual evidence.

Using 08-09-08-1.0 branch build on Win2K It worksforme for D&D (move w/mark as deleted) from IMAP to local folder. Peter, what kind of the IMAP Server are you connecting with? Can you attach an IMAP log here as David described on Comment #21?

Perhaps I wasn't clear enough about what triggers this bug: It only happens with *large* e-mails (those with attachments > 500 kb). The needed size may depend on your internet speed. It *may* also be limited to attachments with certain MIME-types (but that is WAY beyond my skill-level). PS. I'll do the "log" thing after you try the large file and MAPI theory. OK? REOPEN?

It's most likely specific to your imap server. That's why a protocol log is helpful.

It works for me again for moving a message w/attachment over 500kb (Windows 08-23-10-1.0 branch build)for IMAP marking as delete mode. Adding interop for the keywords. This might be specific for your IMAP Server. Peter, attaching an IMAP log will be more helpful! Change QA to Gregg for the follow-up.

I'll try to create and attach a log this weekend (if I can sqeeze in some time).

The IMAP log file i created is much bigger (3 MiBi) than bugzilla allows for attachments (300kibi), so I zipped it (1.2 MiBi) and put it on my server (for a limited time!!!). Here's the link: http://lairo.com/files/IMAP-Log.zip The test-attachment was named: 1701w11m.zip Reproduce: - send mail with attachment (~500 kibi) - receive mail - drag mail to directory in local folders - mail "disappears" from IMAP inbox. :( <-- this bug - Press "Get Msgs" -> mail reappears (with marked-as-deleted red x) --> please REOPEN this bug PS. I would appreciate it, if someone extracted the relevant portions of my logfile and attached them to this bug, so I can delete the full logfile from my (overloaded) server.

this log shows much more than deleting a single message, so it's hard to know how to map what's in the log to the bug Peter is seeing. I notice that Peter seems to be setting labels on these messages, probably with filters. That might be involved, except that this bug predates labels (though this bug has gone through many twists and turns, so who knows...) One thing I noticed, Navin, is that if you drag/drop more than one message at a time (e.g., two messges), then the messages do disappear and reappear, if you're using the imap delete model. That's not what Peter described, but it is a bug that is reproducible.