onNewMailReceived mail extension event creates messagelist for Inbox for messages that have been moved to another folder
Categories
(Thunderbird :: Add-Ons: Extensions API, defect)
Tracking
(Not tracked)
People
(Reporter: danslinuxstuff, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36
Steps to reproduce:
I have an IMAP account with a thunderbird filter set up to move mail based on the To: field. This moves messages from /Inbox to /Inbox2.
What I see is onNewMailReceived, the message list shows the message as coming into /Inbox. Additionally if I then try to get the message details from the ID using message.get(), it has all its information missing and a unix epoch timestamp. See below for an example.
If I set /Inbox2 properties to "When getting new messages for this account, always check this folder" I get a messageList for the /Inbox2, which great, but I ALSO still get onNewMailReceived fired for /Inbox with the same message details.
I see a similar bug here with regards to POP but Im using IMAP. Noting incase its related.
https://bugzilla.mozilla.org/show_bug.cgi?id=1836511
Here are the objects of the troublesome message.
Actual results:
Messages moved by a filter are shown in onNewMailReceived's message list with the original folder and not its destination unless "When getting new messages for this account, always check this folder" is set in which case onNewMailReceived triggers for both
Expected results:
As per the onNewMailReceived API docs:
"Fired when a new message is received, and has been through junk classification and message filters."
I expect the message list to show the message as a new mail in its destination folder after all filters have been applied. I'm not sure whether this means only firing if "When getting new messages for this account, always check this folder" is set or not but certainly it shouldnt send events for both.
Reporter | ||
Comment 1•1 year ago
|
||
As an update, when trying to work around the issue by relying on the messages.get() returning a strange message object, I note that if I call a messages.get() for one of the problematic messages immediately after the onNewMailReceived event, I get a complete message object, though its still pointing at the original folder.
If I delay the messages.get() by 1 second following the onNewMailReceived event, this seems to give enough time for the message to move and it retruns an incorrect message object (as shown above). In my workflow this is enough of a hacky workaround for now where I can check for malformed messages and disregard them. Would still be good to see it fixed one way or the other though. Thanks!
Comment 2•1 year ago
|
||
Found this by chance while reviewing the actual add-on, which had a comment pointing to this bug. Moving the bug into the WebExtension component.
@danslinuxstuff: Is this limited to Thunderbird 115, or can you reproduce this on Beta/Daily as well?
Reporter | ||
Comment 3•1 year ago
|
||
(In reply to John Bieling (:TbSync) from comment #2)
Found this by chance while reviewing the actual add-on, which had a comment pointing to this bug. Moving the bug into the WebExtension component.
@danslinuxstuff: Is this limited to Thunderbird 115, or can you reproduce this on Beta/Daily as well?
I've just tried on 126.0 nightly (MacOS) and its no longer an issue.
In fact it may also be solved in the latest version of 115 too. I'll double check and close this bug off if so.
(as an aside, I was unable to respond to the extension review as I updated a new version and it doesnt allow me to comment anymore)
Comment 4•1 year ago
|
||
(as an aside, I was unable to respond to the extension review as I updated a new version and it doesnt allow me to comment anymore)
You can always reach me at john@thunderbird.net. The error I reported in the review is that it does not work if the directory is not a github directory. Can you build the extracted folder of your uploaded source?
Reporter | ||
Comment 5•1 year ago
|
||
I've tested back as far as 115.6.0 and I cant seem to recreate this issue. Must have been a more local issue. I'll re-open it if it re-appears.
Description
•