Closed Bug 87313 Opened 23 years ago Closed 22 years ago

IMAP mark as delete mode: D&D move to local folder should mark moved message as deleted (NOT remove/clear msgs from thread pane)

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: Peter, Assigned: sspitzer)

References

(Blocks 1 open bug)

Details

(Keywords: imap-interop, platform-parity, regression)

Attachments

(1 file)

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.
QA Contact: esther → sheelar
reassign to karen since this is imap model
QA Contact: sheelar → huang
This is nothing for the delete mode, just the drag & drop behavior change from 
6.1..... There is argument from bug 84905....
Summary: 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) → Sometimes dragging a message from the online imap folder to local folder makes the message disappear in imap folder
Based on bug 84905, resolving won't fix.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Verified.
Status: RESOLVED → VERIFIED
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
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.
Summary: Sometimes dragging a message from the online imap folder to local folder makes the message disappear in imap folder → IMAP mark as delete mode: Should remove/clear msgs from thread pane when D&D(Move) msgs from IMAP to Local?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I already confirmed with Scott & Navin -- this is works as design(current 
design). Marking as won't fix again.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → 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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
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)
Summary: IMAP mark as delete mode: Should remove/clear msgs from thread pane when D&D(Move) msgs from IMAP to Local? → IMAP mark as delete mode: D&D move to local folder should mark moved message as deleted (NOT remove/clear msgs from thread pane)
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.
Blocks: 104166
Keywords: nsbeta1+
Priority: -- → P3
Adding nsbeta1 keyword to all regressions so they *get some love* and attention.
Keywords: nsbeta1
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.
Keywords: nsbeta1
Werid. Anybody see this on OS other than Windows?
Keywords: pp
Blocks: 122274
Status: REOPENED → ASSIGNED
Keywords: nsbeta1+nsbeta1-
Blocks: 155643
wfm. I might have fixed this sometime back.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
OS: Windows NT → Windows 98
Resolution: WORKSFORME → ---
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
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.
Keywords: interop
QA Contact: huang → meehansqa
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: