2040638 - Cannot cancel sending message, cannot resend message after cancelling send - SMTP timeout error on retry

Status: ASSIGNED

(MailNews Core :: Networking: SMTP, defect)

Description

[David]

Attachment: 3.webp

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:150.0) Gecko/20100101 Firefox/150.0

Steps to reproduce:

Compose a new email
Click Send
While "Sending Message" dialog is active, click Cancel
Modify the email or leave as is
Click Send again

Actual results:

Progress bar hangs indefinitely, then the following error appears:

"Sending of the message failed. The message could not be sent because the connection to Outgoing server (SMTP) email.mauriceward.com timed out. Try again."

Message cannot be sent after this. The only workaround is to copy content into a new message.

Expected results:

Message should send successfully on retry after cancellation.

Normal emails (without prior Cancel) send successfully, confirming SMTP server itself works fine

See Also:

• Bug #102521 (closed WORKSFORME, 2001) — same issue
• Bug #113249 (closed INVALID, 2001) — same issue
• Bug #1656240 (closed INCOMPLETE, 2023) — related

Issue still reproducible in Thunderbird 150.0.2 (64-bit) in 2026.
Increasing mailnews.tcptimeout from 100 to 300 does not resolve the issue.

Comment 1

[David]

Additional info:

Outbox is empty. The stuck message does not appear there
Increasing mailnews.tcptimeout from 100 to 300 via Config Editor did not resolve the issue

Comment 2

[Wayne Mery (:wsmwk)]

Are you also seeing this with v151?

Comment 3

[David]

(In reply to Wayne Mery (:wsmwk) from comment #2)

Are you also seeing this with v151?

Yes, the same with v151

Comment 4

[Wayne Mery (:wsmwk)]

QA can you reproduce?

Comment 5

[Ramona Gavrilescu]

Hello
I tested TB 150.0.2(20260506215549) on Windows 11. I composed a new message, clicked Send, canceled the operation while the "Sending Message" dialog was displayed, then clicked Send again. Progress bar hangs and after I received the same error message as described in the report.
The following error was displayed in the Error Console:


NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileInputStream.init] SmtpServer.sys.mjs:647:15 mailnews.smtp: NetworkTimeoutError: a Network error occurred SmtpClient.sys.mjs:487:17     _onError resource:///modules/SmtpClient.sys.mjs:487 mailnews.smtp: SecurityError info: SmtpClient.sys.mjs:502:21     _onError resource:///modules/SmtpClient.sys.mjs:502 mailnews.smtp: SecurityError cert chain: smtp.gmail.com; serial# 00:F3:8A:75:FF:41:ED:B5:64:12:97:11:02:B2:83:FA:D2 <- WE2; serial# 7F:F3:2D:6B:40:9D:15:D5:96:5B:05:87:3A:7C:72:E0 <- GTS Root R4; serial# 7F:E5:30:BF:33:13:43:BE:DD:82:16:10:49:3D:8A:1B SmtpClient.sys.mjs:507:23     _onError resource:///modules/SmtpClient.sys.mjs:507 mailnews.send: Sending failed; The message could not be sent because the connection to Outgoing server (SMTP) smtp.gmail.com timed out. Try again., exitCode=2152398862, originalMsgURI= MessageSend.sys.mjs:368:32     fail resource:///modules/MessageSend.sys.mjs:368     _deliveryExitProcessing resource:///modules/MessageSend.sys.mjs:691     sendDeliveryCallback resource:///modules/MessageSend.sys.mjs:744     onSendStop resource:///modules/MessageSend.sys.mjs:1564     onerror resource:///modules/SmtpServer.sys.mjs:698     _onError resource:///modules/SmtpClient.sys.mjs:515 NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileInputStream.init]

However, I was not able to reproduce the issue consistently. Out of 10 times I managed to reproduce it just once.
I then update TB to 151.0.1(20260522225032) composed a new message, clicked on Send, canceled the operation while sending the message, clicked on Send again, the progress bar hanged for like 40 second but the message was sent afterwards, no error message was displayed.
I then tried again and this time I canceled the sending operation multiple times, after the last cancel I let the Sending Message operation to see if I get the error but the message end up being sent after 30 seconds. No matter how many times I tried, I couldn’t reproduce the scenario on the latest Release channel.

Comment 6

[David]

Good day Ramona,

I tested on 151.0.1 as well. The behavior is inconsistent.. sometimes the message sends successfully after cancelling, but other times it hangs and shows the SMTP timeout error. I was able to reproduce the issue once out of several attempts, similar to your findings.
I also noticed an additional symptom: when cancelling the send operation, Thunderbird sometimes shows a success notification, but the message does not appear in the Sent folder. However, the recipient did receive the email.

Comment 7

[gene smith]

I haven't tested this myself yet, but here's where the change was made to allow canceling smtp sends to work as it did at and before 102: Bug 1816540
There are some comments in that bug by BenB about potential problems with async in the JS code, so possibly that's what we are seeing here. I don't remember trying to go ahead and send the message after canceling the send during my testing.

Comment 8

[gene smith]

For me, with 151 when I send a message the cancel button is now a noop in that the sending continues to completion even after it's clicked. In my test I use a large file to send (16M). Otherwise, with a small file and fast smtp connection, it's hard to cancel before the send is already complete.
I then tested with archived 115.18.0 which has the exact patch from bug 1816540. It works fine. I can cancel the send even after the send is at 90% complete and the message send is aborted correctly. I can do this several times with no problem. Then I do the send again and let it go all the way and it sends correctly and saves to Sent correctly with no hang.
With 115.18.0 when I cancel the send before it gets to 100%, this causes the send dialog to go away and focus goes to the compose window and no additional popup dialogs occur until the next send attempt. With 151, when I cancel, the dialog goes away but then I get the dialog about saving to Sent folder failed.
Anyhow, there have been a few changes that obviously regressed the bug 1816540 patch. The first one got rid of SmtpService and there was another by me. I don't yet know how to fix this, but still trying.

Comment 9

[gene smith]

Looks like the regression is caused by Bug 1922821 pushed 2024-11-27 04:36 +0000. I tested the 2024-11-26 daily and it worked correctly. The daily for 2024-11-27 didn't produce a linux build (for unknown reasons) so I couldn't test that. But the daily for 2024-11-28 did and the build fails (cancel during send does nothing and sending completes and save to sent fails).
I've tried tweaking the code by added some "async" and "awaits" but nothing yet has worked to fix the bug.
FYI, here's the push info for a relevant file: https://hg-edge.mozilla.org/comm-central/log/default/mailnews/compose/src/SmtpServer.sys.mjs

Comment 10

[gene smith]

This change now allows cancel() to be called which stops the smtp send. Apparently "value" is not defined and caused cancel() to never be called so clicking cancel button did nothing. However, there's more below...

diff --git a/mailnews/compose/src/MessageSend.sys.mjs b/mailnews/compose/src/MessageSend.sys.mjs
--- a/mailnews/compose/src/MessageSend.sys.mjs
+++ b/mailnews/compose/src/MessageSend.sys.mjs
@@ -334,20 +334,20 @@ export class MessageSend {
       this.abort();
     }
   }
 
   abort() {
     if (this._aborting) {
       return;
     }
     this._aborting = true;
-    if (this._smtpRequest?.value) {
-      this._smtpRequest.value.cancel(Cr.NS_ERROR_ABORT);
+    if (this._smtpRequest) {
+      this._smtpRequest.cancel(Cr.NS_ERROR_ABORT);
       this._smtpRequest = null;
     }
     if (this._msgCopy) {
       MailServices.copy.notifyCompletion(
         this._copyFile,
         this._msgCopy.dstFolder,
         Cr.NS_ERROR_ABORT
       );
     } else {

With the above fix there is still another problem. You can cancel the smtp send before it reaches 100%. But if you try to send again and there are attachments, the attachment file(s) stored in /tmp get immediately deleted on the 1st send. So if you send again you get an error message that the attachment files can't be found and the smtp send doesn't start. This seems to be regression by bug 2021953. The patch for that bug removed the m_window usage seen here: https://searchfox.org/comm-central/rev/585608544ae8f4b529368362084cbdb5861e5a61/mailnews/compose/src/nsMsgCompose.cpp#4909 which prevents the /tmp attachments files from being removed if the compose window is still present. However, just putting m_window back as it was doesn't seem to help. I don't know a correct solution.

Comment 11

[Brendan Abolivier [:babolivier]]

Edit: Mixed up bug numbers, ignore me

Comment 12

[gene smith]

My change that allowed "cancel" button to work described in comment 10 above was NOT tested with the current c-c head. It was actually from mid April when I did my last full update pull. Today I pulled in the latest m-c/c-c and tested again. The cancel button was still a noop but the comment 10 change now didn't fix the problem.
My comment 10 test above was made with patch for bug 2021953 in place (which was pushed to c-c Apr. 8 and my previous pull was on Apr 15). The next bug affecting "compose" is Bug 2030913. It looks like that where this._smtpRequest is awaited right after the server.sendMailMessage() call occurs here https://searchfox.org/comm-central/rev/515d676833676e10cbc30a5b1d9d4754e71a17bb/mailnews/compose/src/MessageSend.sys.mjs#1205 that it never "resolves" since I can put a dump call before and after the "await" and the after call never occurs if a Send cancel is attempted:

    this._smtpRequest = outgoingListener.requestPromise;

    // Send the message using the server that was retrieved.
    server.sendMailMessage(
      this._deliveryFile,
      parsedVisibleRecipients,
      parsedBccRecipients,
      this._userIdentity,
      this._compFields.from,
      this._smtpPassword,
      this._sendProgress,
      this._compFields.DSN,
      this._compFields.messageId,
      outgoingListener
    );
    dump("gds: await\n");
    await this._smtpRequest;
    dump("gds: awaited\n");    // <-- Never prints if send is cancelled
  }

I only see the "gds: awaited" print if I let the send occur without cancelling and it occurs after all the data is sent, not when sending starts as it should.
When I do cancel, the abort() call occurs but this._smtpRequest (even with .value included) is not completely defined so cancel() call into the "client" code never occurs and the send is never cancelled.
I haven't been able to find a way to fix this and there's a lot going on in bug 2030913 and earlier bugs that affect this. So hopefully someone can take a look at this and suggest a hopefully simple fix.

Comment 13

[Max Emig]

So hopefully someone can take a look at this and suggest a hopefully simple fix.

I also did not see any short and obvious way, this will probably need 50+ LOC changed.

Comment 14

[gene smith]

Max,
Thanks for looking at this.
Just to be clear, even if the possible 50+ local changes fix the "cancel" click being a noop, there still exists the problem that the attachment files in /tmp dir get deleted immediately on the 1st send attempt and prevent another send from occurring from the compose window. I described this regression (seemingly by bug 2021953) near bottom of comment 10.

Comment 15

[Max Emig]

(In reply to gene smith from comment #14)

Max,
Thanks for looking at this.
Just to be clear, even if the possible 50+ local changes fix the "cancel" click being a noop, there still exists the problem that the attachment files in /tmp dir get deleted immediately on the 1st send attempt and prevent another send from occurring from the compose window. I described this regression (seemingly by bug 2021953) near bottom of comment 10.

LOC == Lines of Code, not 50 local changes.

I just wanted to express, this won't be a small hot fix but a little bit larger and it really isn't straight forward, hence it will need careful consideration and design work how this all should work together in the future.

Comment 16

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 2040638 - Fix SMTP cancel hang, premature window close, and nsMsgCompose memory leak. r=#thunderbird-reviewers,john.bieling

This addresses several interconnected issues introduced by the async send
refactoring in Bug 2030913.

1. SMTP Hang on Cancel
   Bug 2030913 changed this._smtpRequest to hold a Promise rather than
   the network request itself, breaking MessageSend.abort(). This patch
   removes this._smtpRequest entirely. Instead, it stores the
   PromiseMsgOutgoingListener directly as this._outgoingListener and
   exposes a cancel() method on it, correctly routing the abort signal
   to the underlying network nsIRequest.

2. nsMsgCompose Memory Leak & Temp Attachment Loss
   This addresses two distinct C++ regressions. First, moving the mDocShell
   cleanup strictly into ~nsMsgCompose() created a circular reference
   that leaked the compose window; nsIMsgCompose.Teardown() now explicitly
   breaks this cycle. Second, cancelling a send previously triggered an
   unconditional DeleteTmpAttachments(), which deleted the draft files and
   broke subsequent send attempts from the same open window. The C++ callbacks
   now strictly check if (!self->m_window) before deleting temp files.

3. Premature Window Close & FCC Race Conditions
   The async refactoring resolved the send operation before the Sent folder
   copy finished, causing the window to close prematurely. _mimeDoFcc now
   uses Promise.withResolvers() to hold the JS state alive. Crucially, to
   prevent this from triggering premature C++ cleanUp() destruction when
   resolved, the promise resolution in notifyListenerOnStopCopy is strictly
   deferred to the next event tick via a finally block and setTimeout.

4. WebExtension onAfterSave Test Expectations
   The browser_ext_compose_saveDraft.js test previously relied on the
   broken synchronous promise resolution, which caused the onAfterSave
   event to fire before the C++ engine could clear the compose window's
   "dirty" flag (expecting isModified: true). With the FCC race
   condition fixed and the promise resolution safely delayed to the next
   tick, the C++ state now correctly updates first. The test has been
   updated to expect the factually correct isModified: false state.

Comment 18

[gene smith]

(In reply to Hartmut Welpmann [:welpy-cw] from comment #16)

Applied your "diff 8" patch and it's working correctly again. Thanks!

Comment 20

[Francesco]

Adjusting summary to what's being fixed in this bug and the bugs duplicated here (for example bug 2044566).

Comment 21

[Francesco]

Based on comment 9, this hasn't been working since TB 135, but there is no such choice in the Version field. TB 140 ESR is broken, too.

Comment 24

[Max Emig]

Attachment: Bug 2040638 - Preserve compose cancel-send lifecycle across FCC and cleanup. r=#thunderbird-reviewers

Comment 25

[Yury]

Attachment: show-dtor-delay.patch

In https://phabricator.services.mozilla.com/D304169 it was suggested, based on AI advice, to copy or move this code:
https://searchfox.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#175-188
from the DTOR to a special "tear down" function that was to be called in ComposeUnload(). I'm not sure that this is necessary, however, I just want to share my observation that the DTOR runs significantly delayed, likely during garbage collection. This is the output of the attached patch when sending has finished and the compose window disappears:

13:02:27.753 Yury> gMsgCompose is true in ComposeUnload() MsgComposeCommands.js:5959:13
13:02:31.575 Yury> nsMsgCompose::~nsMsgCompose() comm\mailnews\compose\src\nsMsgCompose.cpp:176

In this case, the delay was almost 4 seconds. Although the AI reasoning wasn't convincing, before nsMsgCompose::CloseWindow() was removed, the code ran immediately in ComposeUnload() and not delayed in the DTOR. So this may be an argument for implementing the "tear down" function.

Comment 26

[Max Emig]

(In reply to Yury from comment #25)

Created attachment 9593915 [details] [diff] [review]
show-dtor-delay.patch

In https://phabricator.services.mozilla.com/D304169 it was suggested, based on AI advice, to copy or move this code:
https://searchfox.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#175-188
from the DTOR to a special "tear down" function that was to be called in ComposeUnload(). I'm not sure that this is necessary, however, I just want to share my observation that the DTOR runs significantly delayed, likely during garbage collection. This is the output of the attached patch when sending has finished and the compose window disappears:

13:02:27.753 Yury> gMsgCompose is true in ComposeUnload() MsgComposeCommands.js:5959:13
13:02:31.575 Yury> nsMsgCompose::~nsMsgCompose() comm\mailnews\compose\src\nsMsgCompose.cpp:176

In this case, the delay was almost 4 seconds. Although the AI reasoning wasn't convincing, before nsMsgCompose::CloseWindow() was removed, the code ran immediately in ComposeUnload() and not delayed in the DTOR. So this may be an argument for implementing the "tear down" function.

I disagree with this design decision, you are invited to do a follow-up patch strictly focussed on a minor speed improvement.

Comment 27

[Yury]

It's not about "speed improvement", it's about releasing resources at the correct point in time. BTW, here is a stack that shows that the DTOR is called by cycle collection:

00007FFF1D1F82D5: nsMsgCompose::~nsMsgCompose
00007FFF1D23B5F0: nsMsgCompose::~nsMsgCompose
00007FFF1D1F8DE4: nsMsgCompose::Release
00007FFF15DAEBB7: mozilla::SegmentedVector<nsCOMPtr<nsISupports>,4096,mozilla::MallocAllocPolicy>::PopLastN
00007FFF15D95DC7: mozilla::dom::DeferredFinalizerImpl<nsISupports>::DeferredFinalize
00007FFF15D964E2: mozilla::IncrementalFinalizeRunnable::ReleaseNow
00007FFF15D874F8: mozilla::CycleCollectedJSRuntime::FinalizeDeferredThings
00007FFF15D873D2: mozilla::CycleCollectedJSContext::AfterProcessTask
00007FFF161E0A39: XPCJSContext::AfterProcessTask
00007FFF15F0748B: nsThread::ProcessNextEvent
00007FFF15F0DD31: NS_ProcessNextEvent
00007FFF16057EF8: mozilla::ipc::MessagePump::Run

Comment 28

[Max Emig]

(In reply to Yury from comment #27)

It's not about "speed improvement", it's about releasing resources at the correct point in time. BTW, here is a stack that shows that the DTOR is called by cycle collection:

00007FFF1D1F82D5: nsMsgCompose::~nsMsgCompose
00007FFF1D23B5F0: nsMsgCompose::~nsMsgCompose
00007FFF1D1F8DE4: nsMsgCompose::Release
00007FFF15DAEBB7: mozilla::SegmentedVector<nsCOMPtr<nsISupports>,4096,mozilla::MallocAllocPolicy>::PopLastN
00007FFF15D95DC7: mozilla::dom::DeferredFinalizerImpl<nsISupports>::DeferredFinalize
00007FFF15D964E2: mozilla::IncrementalFinalizeRunnable::ReleaseNow
00007FFF15D874F8: mozilla::CycleCollectedJSRuntime::FinalizeDeferredThings
00007FFF15D873D2: mozilla::CycleCollectedJSContext::AfterProcessTask
00007FFF161E0A39: XPCJSContext::AfterProcessTask
00007FFF15F0748B: nsThread::ProcessNextEvent
00007FFF15F0DD31: NS_ProcessNextEvent
00007FFF16057EF8: mozilla::ipc::MessagePump::Run

You might not be wrong, but I was not able to reproduce any real-world impact in my test suite and consider refactoring it even further much more risky than leaving it closer to the original shape.

If you want to see it included in my patch, can you produce something more akin to steps to reproduce like in our default Bugzilla template rather than a statement why the code is not perfect?

Comment 29

[Yury]

As I wrote (quote): ... a special "tear down" function that was to be called in ComposeUnload(). I'm not sure that this is necessary.

Just to summarise:

1. State before bug 2030913:
   This code was run in ComposeUnload() when the compose window closed.
2. Prior AI advice: Restore it, however, in the AI code mMsgSend was in fact not reset in the "tear down" function.
3. Additional observation: DTOR, where the code is now, runs seconds later during cycle collection.

I have no further insights.

Clearly, the bug reported here is about the refactoring in the three regressors where two regressors (bug 1922821, bug 2030913) changed the semantic of the SMTP request and broke the ability to cancel, part of the third regressor (bug 2021953 ) caused the attachments to be deleted too early. That part of the one regressor also delayed the cleanup code may be totally fine (despite lots of wordy Gemini argumentation to the opposite).

Comment 30

[Max Emig]

Clearly, the bug reported here is about the refactoring in the three regressors where two regressors (bug 1922821, bug 2030913) changed the semantic of the SMTP request and broke the ability to cancel, part of the third regressor (bug 2021953 ) caused the attachments to be deleted too early.

I can reproduce that user facing behaviour manually as well as in Mochi- and XPC-tests.

I have no idea how what you are describing would cause user impact except for a slightly longer time to send which for the official Gmail clients by default is even longer and they are framing cancel as recall.

Sure, refactoring that eventually and possibly introducing an artificial configurable delay similar to the status quo would be nice, however similar more or less aimless refactors in the past were exactly what brought us to huge regressions like this one.

Comment 31

[Magnus Melin [:mkmelin]]

As long as garbage collection takes care of it, yes let's not do it manually, jumping hoops to do so.

Comment 32

[Yury]

(In reply to Max Emig from comment #30)

I have no idea how what you are describing would cause user impact ...

It doesn't cause user impact unless it breaks something.

... except for a slightly longer time to send ...

There must be a misunderstanding. The delay is in the internal cleanup of some variables. That's not user-facing, but read the detailed analysis below.

Sure, refactoring that eventually and possibly introducing an artificial configurable delay ...

Again, there was never any notion of a user-facing delay.

Let's look at the code that got shifted in bug 2030913:
https://searchfox.org/comm-central/rev/b640f675072d3e0097a73cb46af7f57694099fd4/mailnews/compose/src/nsMsgCompose.cpp#175-186

  if (mDocShell) {
    nsCOMPtr<nsIMsgComposeService> composeService =
        mozilla::components::Compose::Service();
    if (composeService) composeService->UnregisterComposeDocShell(mDocShell);
  }
  mDocShell = nullptr;

  // ensure that the destructor of nsMsgSend is invoked to remove
  // temporary files.
  mMsgSend = nullptr;
  m_editor = nullptr;

I will spare you the details, but it's pretty irrelevant when (and even whether) the docshell of the editor is deregistered and the docshell and editor are cleared. The registered docshells are only used for GetMsgComposeForDocShell() in nsMsgContentPolicy.cpp.

However, bug 2030913 changed the nulling of mMsgSend. Before it was nulled on nsMsgCompose::CloseWindow() which ran at ComposeUnload() well before the compose DTOR. So the compose DTOR would have always executed this block upon window closure:
https://searchfox.org/comm-central/rev/b640f675072d3e0097a73cb46af7f57694099fd4/mailnews/compose/src/nsMsgCompose.cpp#168-173
(Let's recall that the Gemini proposal missed this, its "teardown" was about the other variables.)

So this analysis leads me to the conclusion that currently, despite temporary attachments being deleted where they shouldn't be, they are also left behind where they should have been deleted. Not totally user-facing, unless the user digs into their temp folder.

@mkmelin: Or was that taken into consideration in bug 2030913?

I would also question the comment "ensure that the destructor of nsMsgSend is invoked to remove temporary files". More to the truth would be: "Make sure to remove the reference to the send object since its presence determines wither temporary files are deleted in the compose DTOR". But as detailed, that comes too late since the test is above.

Comment 33

[Max Emig]

they are also left behind where they should have been deleted.

I am testing exactly that in the real world.

Comment 34

[Yury]

Yes, well, I've come to the conclusion that "temporary attachments" happen when messages with attachments are forwarded. The attachments are extracted from the original message and placed into the temp folder. And yes, in current Daily they are removed upon send, but one bug duplicated here reported that they were also removed on save (a variation of send), which is not correct.

I noticed that the obsolete code behind if (!mMsgSend) has been replaced with if (!mSendInFlight), so that takes care of this. Thank you.

Comment 36

[Max Emig]

Leaving this open for the possibility of tests and public user feedback.

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7a2157b4203f
Preserve compose cancel-send lifecycle across FCC and cleanup. r=mkmelin

Comment 38

[Francesco]

Thanks, this works now. I cancelled sending of a big message and the cancel itself as well as the resending both worked.
Next I tried to forward a large message, which is the scenario that creates the temporary attachments. I watched those in the temp directory. Upon first cancel, the temporary attachments were maintained. Once the message was abandoned, they were deleted.

I was actually going to set the status to VERIFIED, but the bug isn't marked as fixed yet. Will you be adding a test since this is not the first time the function broke?

Comment 39

[Max Emig]

(In reply to Francesco from comment #38)

Thanks, this works now. I cancelled sending of a big message and the cancel itself as well as the resending both worked.
Next I tried to forward a large message, which is the scenario that creates the temporary attachments. I watched those in the temp directory. Upon first cancel, the temporary attachments were maintained. Once the message was abandoned, they were deleted.

I was actually going to set the status to VERIFIED, but the bug isn't marked as fixed yet. Will you be adding a test since this is not the first time the function broke?

Thank you for the kind feedback.

My test suite exceeds 1000 LOC and is not really of my or really anyones quality standard, yet.

You can inspect the tests here: https://hg-edge.mozilla.org/try-comm-central/rev/657644173fc4fcc061d58fc626f22f07540c6277

Comment 40

[Francesco]

I'm not a developer. You could upload the test(s) and ask for feedback.