628389 - delete notification not getting sent when doing an offline fcc to the sent folder w/ pseudo hdr.

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[David :Bienvenu]

Now that bug 574441 is fixed, there are issues with code that holds onto stale msg keys, like the db view code. It needs to listen for msgKeyChanged notifications or some how deal with pseudo-hdrs becoming real headers. It would also be good to deal with code that holds onto msgHdrs not to have to know about this (i.e., change the msg key automatically).

Comment 1

[Jonathan Protzenko [:protz]]

Thanks for filing the followup bug! :-)

Comment 2

[David :Bienvenu]

Looking at the code, we should be sending a msgHdrDeleted dbchangelistener notification when the fake header is deleted, but I noticed that we're not doing this in the case where the sent folder is open in the UI (we do the update folder, but don't go through the offline sync code). So I think the issue may be that we're not doing an offline sync for that folder in this case. I'll look into a fix.

Comment 3

[David :Bienvenu]

Attachment: fix case where sent folder is open in UI

This moves the updateFolder call that we make when the sent folder is open in the UI to *after* the code that adds the message to the offline store and adds the pseudohdr. This makes us handle the offline event immediately, and remove the pseudohdr. I'm not sure what the issue is with the conversation add-on when it displays a unified folder over the inboxes and sent folders so I'll investigate that next. I also need to make sure this change doesn't break any unit tests...

Comment 4

[David :Bienvenu]

Attachment: fix unit tests

This makes unit tests pass by passing in the url listener that the detach code expects (the fact that the detach unit test was failing shows that this code is covered by unit tests...)

Protz, I couldn't reproduce the problem with conversation view w/ this patch applied, so I'm hopeful it will fix that issue as well.

Comment 5

[Jonathan Protzenko [:protz]]

I'm afraid this doesn't fix the issue, although it certainly does help. Here's my STR:
- have your unified inbox also search sent folders,
- select the unified inbox in the folder pane,
- select a collapsed thread in the unified inbox,
- conversation view displays, focus quick reply, type something, send it
- a new message header is added to the view, we rebuild the conversation view right away
- the error console displays: 	[Exception... "Component returned failure code: 0x80550008 [nsIMsgMessageService.streamMessage]"  nsresult: "0x80550008 (<unknown>)"  location: "JS frame :: resource://conversations/stdlib/msgHdrUtils.js :: msgHdrToMessageBody :: line 134"  data: no]

What happens is the view code fires summarizeThread right away, and we rebuild the conversation at once. We figure out the conversation is the same, except for that last message that just arrived. Since Gloda hasn't indexed it yet, we try to stream it through gloda's MsgHdrToMimeMessage facility. That fails, so we resort to https://github.com/protz/thunderbird-stdlib/blob/master/msgHdrUtils.js#L130 which fails as well...

Comment 6

[David :Bienvenu]

The problem is the new new msg hdr is getting deleted fairly quickly, but you're not listening for the notification. The easiest thing to do is probably just to call nsIMsgDatbase.ContainsKey(msgKey) on the msghdr's key before trying to stream the message. Or you could listen for the delete notification on nsIFolderListener or the msgKeyChanged notification on the nsIMsgFolderListener.

Comment 7

[David :Bienvenu]

fixed on trunk - I'm trying to reproduce the unified folders issue.

Comment 8

[David :Bienvenu]

pushed wrong patch first time - correct changelog is http://hg.mozilla.org/comm-central/rev/e49518c1ee1b