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

Steps to reproduce:

In Thunderbird version 91.2.1
Create a second account in thunderbird.
Receive an email to that account containing an email address or mailto link in the body.
Click the link

Actual results:

A new email to the associated recipient opens, but uses the default identity and not the one associated with the click.

Expected results:

A new email from the secondary account should open instead.

If I right-click the email link, and click "Compose Message To", the correct identity is chosen.

This appears to be a duplicate of bug 64267, which is marked as resolved.

Thanks for reporting, will take a look.

aWindowContext is null at https://searchfox.org/comm-central/rev/6c069446f28bc9f6b57c1f973fe0e15447532a1f/mailnews/compose/src/nsMsgComposeContentHandler.cpp#95-96, maybe related to e10s changes.

Hello, thank you for your fast actions.

Similar bug:

When I create a new message from my secondary account,
then change the "From" address to "Customize From Address" and type a freeform "From" address,
then save the draft to my secondary account, then edit the message, the default identity is used to try to send from the freeform address instead of the secondary account where the draft resides.

I'm not finding a duplicate in https://mzl.la/3D1XrVl, unless a variation is Bug 1736887 - Replying to a Local Folders message does not use default account

Note, context menu selects the correct account - right+click > compose message to

For me the default account is used whether E10s is enabled or disabled, so it's not that. I think we'll need to chase the missing context up the call stack and figure out why it's not there. The comments say:

Note that m_originalContext can be nullptr when running this in the parent process on behalf on a docshell in the content process, and in that case we only support content handlers that don't need the context.

But we're in the parent process and so is the docShell, so that doesn't apply to us.

I think it would be much easier if we just abandoned this approach and use JSActors, like we did with vCard links. So I'm going to do that.

The content handler (nsMsgComposeContentHandler) appears to be used for other reasons, like using a mailto: URL as a command-line argument, so I'm not removing it.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/8e28a3446dd2
Handle clicks on mailto: links with an actor instead of a content handler. r=mkmelin

:-(

Comment on attachment 9250467 [details]
Bug 1737637 - Handle clicks on mailto: links with an actor instead of a content handler. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): unknown
User impact if declined: wrong identity can be used when composing to a recipient linked in a message
Testing completed (on c-c, etc.): landed 2 days ago
Risk to taking this patch (and alternatives if risky): should be low, although there was a follow-up patch because I am an idiot, it needs to be uplifted too

Comment on attachment 9250467 [details]
Bug 1737637 - Handle clicks on mailto: links with an actor instead of a content handler. r=mkmelin

[Triage Comment]
Approved for beta

Thunderbird 95.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/99a7e6531f09
https://hg.mozilla.org/releases/comm-beta/rev/adfadce3ef3c

Comment on attachment 9250467 [details]
Bug 1737637 - Handle clicks on mailto: links with an actor instead of a content handler. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): unknown
User impact if declined: wrong identity can be used when composing to a recipient linked in a message
Testing completed (on c-c, etc.): in 95 beta 4
Risk to taking this patch (and alternatives if risky): should be low, although there was a follow-up patch because I am an idiot, it needs to be uplifted too

Comment on attachment 9250467 [details]
Bug 1737637 - Handle clicks on mailto: links with an actor instead of a content handler. r=mkmelin

[Triage Comment]
Approved for esr91 ... with followup patch

Thunderbird 91.4.0:
https://hg.mozilla.org/releases/comm-esr91/rev/46f311638bcc
https://hg.mozilla.org/releases/comm-esr91/rev/cf4fbd2a93f0