Closed Bug 598626 Opened 14 years ago Closed 12 years ago

Can not move a Gmail message from folder to trash

Categories

(MailNews Core :: Networking: IMAP, defect)

1.9.1 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: peter.c.slacik, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.13) Gecko/20100914 SeaMonkey/2.0.8

Gmail is storing each message just once, but can display it as if stored multiple times in different IMAP folders (called Labels). The only way to really delete a message (or move it to "Local Folders" without leaving it in Gmail) is to move it into Trash (and move it from Trash to some Local Folder afterwards).

After moving a handful of messages from e.h. Inbox to [Gmail]/Trash to Local Folders/Friends/Johnny, suddenly nothing can be moved into Trash folder anymore - the messages "just stay" in the original folder. Compacting or emptying the Trash does not help, the only solution is to restart SeaMonkey.

Reproducible: Always

Steps to Reproduce:
1. Drag and Drop a message from Inbox or other Gmail subfolder to [Gmail]/Trash (the message will disappear from both Inbox and all Messages)
2. Move the message from [Gmail]/Trash to some subfolder of Local Folders
3. (Optionally compact or empty the [Gmail]/Trash folder - the message will finally completely disappear from the IMAP account. Not necessary to reproduce the bug.)
4. Repeat 1.-3. for 5-6-7 messages. It can also be a bunch of selected messages.
Actual Results:  
Suddenly a message can not be moved into [Gmail]/Trash - it simply stays in the previous folder.
After a SeaMonkey restart, Messages can again be moved into [Gmail]/Trash. (Again just for some short time.)

Expected Results:  
In older versions (at most some 3-4 releases ago?), a lots of messages could be selected and moved into Local folders without any problems.

The application seems to work correctly otherwise.
This last sentence "In older versions (at most some 3-4 releases ago?), a lots of messages could be selected and moved into Local folders without any problems." should better be:
"In older versions (at most some 3-4 releases ago?), a lots of IMAP messages could be selected and moved into Trash without any problems."
Sounds like a back end issue. Moving to MailNews Core. Also SeaMonkey 2.1 is out later this month. Please check if you still have this problem with the new version.
Component: MailNews: Backend → Networking: IMAP
Product: SeaMonkey → MailNews Core
QA Contact: mailnews-backend → networking.imap
Version: unspecified → 1.9.1 Branch
(In reply to comment #2)
> SeaMonkey 2.1 is out later this month. Please check
> if you still have this problem with the new version.
I will, as soon as it gets out.
BTW, with 2.0.14 it still does happen. Sooner or later...
If it will once helps for debugging: I'm usually selecting the messages (to be temporarily moved into Trash) using a "Saved Search 'folder'" - its properties contain which messages from which (multiple) IMAP subfolders (a.k.a GMail's "labels") should be selected, them I move all of them into IMAP's Trash, then finally into some Local folder.

(I'm not sure anymore, but I hope that while writing the initial bug report, I've tested it also using drag-and-drop from one plain IMAP folder.)
(In reply to comment #3)
> (In reply to comment #2)
> > SeaMonkey 2.1 is out later this month. Please check
> > if you still have this problem with the new version.
> I will, as soon as it gets out.
> BTW, with 2.0.14 it still does happen. Sooner or later...

SeaMonkey 2.2 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2) is out, the bug can still be reproduced.

(I've moved 3 messages from IMAP's "Saved Search 'folder'" into the same IMAP's Trash, from Trash into a Local folder, Compacted the IMAP's Trash. Afterwards I'm not able to move any other message into this Trash folder. Not even from the IMAP's Inbox - the source folder does not matter. I can still move messages between IMAP subfolders or from the Trash to any other folder, just not towards the Trash.)
(In reply to comment #5)
> SeaMonkey 2.2 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110706
> Firefox/5.0 SeaMonkey/2.2) is out, the bug can still be reproduced.
> 
> (I've moved 3 messages from IMAP's "Saved Search 'folder'" into the same
> IMAP's Trash, from Trash into a Local folder, Compacted the IMAP's Trash.
> Afterwards I'm not able to move any other message into this Trash folder.
> Not even from the IMAP's Inbox - the source folder does not matter. I can
> still move messages between IMAP subfolders or from the Trash to any other
> folder, just not towards the Trash.)
With the same running process, I've tried to reproduce it on other GMail IMAP account, but the same steps worked there flawlessly in many iterations. But as far as I can compare the two accounts' settings, they appear to be completely the same...
Peter, does this reproduce with version 17?  And can you get a imap:5  protocol log?    https://wiki.mozilla.org/MailNews:Logging
Flags: needinfo?(peter.c.slacik)
I'm sorry for a late response... Not that I knew, what "version 17" means, but on "User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 Build identifier: 20121129191119" I can not reproduce my problem anymore. (Should I create the imap:5 protocol log anyway?)
Flags: needinfo?(peter.c.slacik)
(In reply to Peter Slacik from comment #8)
> I'm sorry for a late response... Not that I knew, what "version 17" means,
> but on "User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0)
> Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 Build identifier:
> 20121129191119" I can not reproduce my problem anymore. (Should I create the
> imap:5 protocol log anyway?)

We'll just call it WORKSFORME. If you are able to reproduce the problem again, just re-open the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.