1975854 - compose.onAfterSend not always called

Status: RESOLVED FIXED

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

Description

[Günter Gersdorf]

Steps to reproduce:

Have two add-ons which adds a listener for compose.onAfterSend

Actual results:

Only one listener is called. The other fails in the onSuccess block on the line
https://searchfox.org/comm-central/source/mail/components/extensions/parent/ext-compose.js#1474
TB than continues to the onFailure block but also fails at the same statement.

Expected results:

Both listeners should be called.

Comment 1

[Günter Gersdorf]

This bug prevents two of my add-ons from coexisting...

Comment 2

[John Bieling]

Thanks for the report, Günter. Which two add-ons are that? Could you check this in Daily, if it may have been fixed by bug 1959939? I changed the order of some calls, which were different compared to the onBeforeSend event.

Comment 3

[Günter Gersdorf]

Attachment: testOnAfterSend1.xpi

Comment 4

[Günter Gersdorf]

Attachment: testOnAfterSend2.xpi

Comment 5

[Günter Gersdorf]

Tested with daily 2025-11-16 and fresh profile: No change, only one add-on is called.
I've tested with two nearly identical minimal add-ons, see attachments. Only the console message from the first installed add-on is shown.

Comment 6

[John Bieling]

Attachment: WIP: Bug 1975854

Comment 7

[John Bieling]

Attachment: Bug 1975854 - Fix race condition when multiple extensions register a listener for the compose.onAfterSend event. r=#thunderbird-reviewers

The compose window may be destroyed while the event result is still being
prepared asynchronously, which could cause some listeners to not notify
their handlers.

This patch introduces the onConvertSync callback, which is executed while
the compose window is guaranteed to exist. Because this callback must be
called from inside MsgOperationObserver, the calls to the other callbacks
(onSuccess and onFailure) have also been moved there.

Comment 8

[Günter Gersdorf]

Will this approach garantee that information i have added to the compose window via messenger.sessions.setTabValue() are accessible in the onAfterSend listener?

Comment 9

[John Bieling]

I don't think so, the window is probably destroyed by the time onAfterSend is called, which is the reason why the current implementation of the event fails for your second extension.

Edit: I added a note to the documentation.

Comment 10

[John Bieling]

try: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=0809df6831e710529a8ece87baffce02ad16dbde

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4c95576f4aaf
Fix race condition when multiple extensions register a listener for the compose.onAfterSend event. r=mkmelin