1855486 - messenger.messages.update works on old message ID after message has been moved, changes message in its new location

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, defect, P2)

Description

[Jonathan Kamens]

If you call messenger.messages.move to move a message to a different folder, and then you call messenger.messages.update using the old message ID, the call to messenger.messages.update works and updates the message in the new folder, even though it now has a new, different ID.

Comment 1

[John Bieling (:TbSync)]

From https://github.com/thunderbird/webext-docs/issues/59#issue-1126540000

After a message is moved, I can still get a message at the old id, it has a date (1970) and a folder set.

Comment 2

[John Bieling (:TbSync)]

Attachment: Bug 1855486 - No longer allow operations on moved/deleted messages. r=BenC

The WebExtension API maps unique ids to messages and internally uses the
tuple of folder.URI and msgHdr.messageKey. It was assumed that
deleted or moved messages will fail this lookup:

const msgHdr = folder.msgDatabase.getMsgHdrForKey(messageKey);

That however is not true. The msgDatabase still knows the messageKey
and returns an empty msgHdr: the folder property and the messageKey
properties are set, everyhing else is zero/null.

Comment 3

[John Bieling (:TbSync)]

Attachment: Bug 1855486 - Delete moved or deleted messages from WebExtension message tracker. r=mkmelin

The WebExtension API maps unique WebExt message IDs to messages and
internally uses the tuple of folder.URI and msgHdr.messageKey to
identify messages. It was assumed that deleted or moved messages will
fail this lookup:

const msgHdr = folder.msgDatabase.getMsgHdrForKey(messageKey);

That however is not true. The msgDatabase still knows the messageKey
and returns an empty msgHdr: the folder property and the messageKey
properties are set, everyhing else is zero, null or an empty string.

This patch enforces the deletion of tracker entries of moved or deleted
messages in the MailServices.mfn.msgsDeleted and
MailServices.mfn.msgsMoveCopyCompleted events.

When a known/tracked message gets moved, and its tracking data is
deleted, the convert() process for the messages.onMoved and the
messages.onDeleted events will generate a NEW message ID, because the
cached message headers still references the old messageKey which are
now "new". These events however must return the already known IDs for
these messages.

The only way to solve this is by storing the actual WebExt message ID in
the cached header. This ensures that the old messageKey is used to
lookup the WebExt message ID before(!) they are purged from the tracker.
The cached header can then be used without limitation until all
reporting operations have finished.

This may also fix an intermittent issue, where the cached destination
header of IMAP moves was converted to a WebExt MessageHeader only after
the IMAP key swap occured. The cached message header was then
pointing to the wrong message. See Bug 1806990.

Depends on D224927

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/353bdf8604c8
Delete moved or deleted messages from WebExtension message tracker. r=mkmelin