onNewMailReceived listener unreliable
Categories
(Thunderbird :: Add-Ons: Extensions API, defect, P2)
Tracking
(Not tracked)
People
(Reporter: 52qtuqm9, Assigned: TbSync)
References
Details
Attachments
(2 files)
I add a listener with messenger.messages.onNewMailReceived.addListener in my add-on when it loads. Then after adding the listener I scan all the messages currently in the user's inbox to catch any that were there before I added the listener. Nonetheless, I subsequently discovered that there are messages in the user's inbox that my add-on never saw, because they didn't show up in the scan of all messages in the folder and my listener was never called about them.
Jury's still out on whether the listener is unreliable in general or just during this startup period.
|
Reporter | |
Comment 1•2 years ago
|
||
More data about this. I received an email at 17:57 tonight. It went into my inbox. Remote Content By Folder (my add-on) should have received a listener call about it. It never did.
My guess is that the message came in while my laptop was sleeping and for some reason the listener isn't being called on messages that come in when Thunderbird is "catching up" after being offline for a while. This may be the same reason why the listener isn't being called for messages that come in right when Thunderbird starts up.
|
||
Comment 2•2 years ago
|
||
(In reply to Jonathan Kamens from comment #1)
My guess is that the message came in while my laptop was sleeping and for some reason the listener isn't being called on messages that come in when Thunderbird is "catching up" after being offline for a while. This may be the same reason why the listener isn't being called for messages that come in right when Thunderbird starts up.
This could be related to bug 1850679.
|
Assignee | |
Comment 3•2 years ago
|
||
@Jonathan: Are you using an OAUTH IMAP account (like GMAIL)? Are you able to reproduce this with a normal non-OAUTH IMAP account?
|
|
Reporter | |
Comment 4•2 years ago
|
||
This is happening with a regular username/password IMAP account. On a Cyrus IMAPd server, specifically.
Every workaround I've tried for this problem has failed. It doesn't seem to be restricted to startup and offline -> online transitions. For whatever reason, I am frequently not getting notifications for all new messages that come into my inbox. The next theory I'm going to test when I have a few minutes to code it is that sometimes when multiple emails come in at the same time the notification doesn't include all of them. If that's the case then the workaround is going to be to rescan at least my entire inbox every time I get a notification.
|
|
Assignee | |
Comment 5•1 years ago
|
||
Any news on solid steps to reproduce this issue? Is it also happening when the laptop was not sleeping?
|
|
Assignee | |
Updated•1 years ago
|
|
|
Reporter | |
Comment 6•1 years ago
|
||
I don't know anything more about why this is happening or how to reproduce it. All I can tell you is it seems to happen pretty often. I eventually gave up on relying on the events and coded my extension to scan folders regularly looking for messages it didn't get notified about.
As far as I can tell, the event is fired only if messages land in the Inbox folder, i.e. when messages aren't moved to other folders by filters.
According to the api docs this is not the expected behaviour
https://webextension-api.thunderbird.net/en/latest/messages.html#onnewmailreceived
Fired when a new message is received, and has been through junk classification and message filters.
|
|
Reporter | |
Comment 8•1 years ago
|
||
As far as I can tell, the event is fired only if messages land in the Inbox folder
That's bug 1848787, which is different from this bug.
(In reply to Jonathan Kamens from comment #8)
As far as I can tell, the event is fired only if messages land in the Inbox folder
That's bug 1848787, which is different from this bug.
Hi Jonathan, no it isn't. That bug is about special folders other than Inbox. My complaint is about the reliability of onNewMailReceived for normal folders (i.e. subfolders of Inbox).
Why is the event not triggered if an email is received and a filter moves it to a subfolder of Inbox?
|
|
Reporter | |
Comment 10•1 years ago
|
||
Well, if you don't think it's bug 1848787, fine, but it's not this bug. This bug is specifically about emails that absolutely should have been notified about, that don't fall into the filter problem you're mentioning, but notifications still weren't received.
If you're reliably seeing messages moved by filters not getting notified about, that's a different bug. I suggest you open a new bug for it.
|
||
Comment 11•1 years ago
|
||
(In reply to Jonathan Kamens from comment #10)
Well, if you don't think it's bug 1848787, fine, but it's not this bug. This bug is specifically about emails that absolutely should have been notified about, that don't fall into the filter problem you're mentioning, but notifications still weren't received.
If you're reliably seeing messages moved by filters not getting notified about, that's a different bug. I suggest you open a new bug for it.
Jonathan I see your point. I have followed your advice and opened a new bug 1864870.
|
|
Assignee | |
Updated•7 months ago
|
|
||
Comment 12•3 months ago
•
|
||
I tested this with 128.6.1esr and 135.0b4.
It seems that the problem occurs when the new mail notification is not displayed.
I identified two cases, thought there may be others (such as the one mentioned in comment 1):
- The "Show an alert" option in "When new messages arrive" is unchecked.
- Clicking on the "Get new messages" button
I was able to reproduce the issue consistently.
You can find the full thread in the add-on dev room.
|
|
Assignee | |
Comment 13•2 months ago
|
||
The BiffState approach turned out to be cumbersome, specifically if
filters are involved. Instead of using the BiffState property, we now
simply report new messages which have the new flag set.
We keep the original behavior to bunch up multiple new message events
per folder.
|
||
Updated•2 months ago
|
|
|
Assignee | |
Comment 14•2 months ago
•
|
||
This add-on includes an Experiment which uses the same mechanism as the new implementation introduced in D237936. It can be installed in Thunderbird 128 ESR to try out if any messages are still missed, without having to wait for the patch to be backported from Thunderbird Daily to Thunderbird 128 ESR.
Testing is appreciated, thanks!
The add-on will print an entry for each received message to the console.
|
|
Reporter | |
Comment 15•2 months ago
|
||
I attempted to plug the experiment into Remote Content By Folder but it appears that the event listener is getting passed an array of message subjects instead of a MessageList? Given that I don't think I can test this in real-world conditions.
|
|
Assignee | |
Comment 16•2 months ago
|
||
I wanted to go the extra mile and provide a self-contained technology demonstrator, which cannot do any harm and can be easily tested. I cannot provide a drop-in replacement, as that needs extensive testing and may introduce unwanted side effects if used in real add-ons.
To allow real-world testing with your add-on, I started a try-run where you could pull executables of the patched build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=d9eef29dbe3f543118c8b493ceab2126f68dd04a
|
|
Assignee | |
Comment 17•2 months ago
|
||
Removing the dependency from Bug 1850679, as we no longer depend on BiffState information: A BiffState event only gives us the original folder, "inbox" for example, but if the message is moved by filters into a different folders (not being a sub-folder of the original folder), before junk classification, the current system does not know where the message is and cannot report it.
|
|
Reporter | |
Comment 18•2 months ago
|
||
(In reply to John Bieling (:TbSync) from comment #16)
I wanted to go the extra mile and provide a self-contained technology demonstrator, which cannot do any harm and can be easily tested. I cannot provide a drop-in replacement, as that needs extensive testing and may introduce unwanted side effects if used in real add-ons.
To allow real-world testing with your add-on, I started a try-run where you could pull executables of the patched build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=d9eef29dbe3f543118c8b493ceab2126f68dd04a
Thanks! I will test for a week and report back.
|
|
||
Updated•2 months ago
|
|
|
Assignee | |
Updated•2 months ago
|
|
||
Comment 19•2 months ago
|
||
Pushed by john@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/73ba995def58
Change implementation of messages.onNewMailReceived event to no longer use BiffState. r=mkmelin
|
|
Reporter | |
Comment 20•2 months ago
|
||
Reopening because I am still not receiving notifications for all new messages.
For example, this morning when I launched Thunderbird (the try version you gave me to test) I received two emails one right after the other, as indicated by the IMAP Order Received column. I have two different extensions installed that use onNewMailReceived. As far as I can tell, both of these extensions were only notified about one of those two messages.
Description
•