510595 - Remnants of email in preview pane after sending to junk.

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Lint Hasenpfeffer]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090813 Lightning/1.0pre Shredder/3.0b4pre

With the preview pane open, and an email being displayed, marking the email as junk, will send it to the assigned junk folder (this feature works fine), however if it is the last/only email in the mailbox, there will be remnants in the preview pane.

The account in question is using imap (not gmail), and the spam folder is on the server for that account.

Reproducible: Always

Steps to Reproduce:
1. Have 1 email in mailbox being displayed in the preview pane
2.Mark it as junk
3.
Actual Results:  
header information and remote content block banner (if applicable) remains.

Expected Results:  
empty preview pane.

Comment 1

[Lint Hasenpfeffer]

Attachment: Preview pane remnant

Comment 2

[David :Bienvenu]

this is probably a dup of an already filed bug (I think davida has seen this).

But these steps actually work for me to reproduce this bug, so I'll try to deal with the issue in this bug. I don't know if bonking the junk button in the header area is the issue or not, or if the issue somehow has to do with the junk notification bar...

Comment 3

[Lint Hasenpfeffer]

If it is I apologize, finding the right word matrix for a bug is, well non-trivial.

Comment 4

[David :Bienvenu]

This happens with imap, but not local msgs, from what I can tell. I was able to reproduce it on Windows as well. We seem to be running a url in the message pane immediately after running the about:blank url, and they collide. This would seem to be an issue with figuring out what next to load when the delete is finished.

Comment 5

[David :Bienvenu]

What's happening here is that we're reloading the message when we get the junk status changed notification, even though we're going to delete the message immediately after. We're also clearing the message pane, which means loading about:blank. The urls are colliding, and bad things happen. I'm not sure if url to load the message is getting interrupted after the headers are displayed, before the message body gets displayed. I thought I saw in the debugger that it was the about:blank url that got interrupted, but maybe I'm confused...

It shouldn't be too hard to fix this issue, by not reloading a junk message that's about to get removed, but I am wondering if this url interruptus problem can account for some of the other cases where the message loaded doesn't match the header displayed...

Comment 6

[David :Bienvenu]

Attachment: proposed fix

this fixes the code not to reload if we're just going to move the message anyway.

I'm going to try to dig a little deeper into what goes wrong when this patch is not applied, i.e., if we can better handle the case where a message load is aborted...

Comment 7

[Magnus Melin [:mkmelin]]

Already handling this in bug 512279.

Comment 8

[WADA:World Anti-bad-Duping Agency]

DUPing to bug of very different summary/phenomenon produces confusion, and many users don't search DUP'ed bugs. Re-opening, with setting dependency to bug 512279.

By the way, as David says, I also saw some bugs for this bug's phenomenon.
I'll do DUPing for same phenomenon to this bug, if I'll reach such bugs again.