Steps to reproduce:

Clicked on a "mailto:" link inside some email.

Actual results:

It opened a new compose window but without the information supplied by the mailto: link. It started a empty compose window with the default identity selected and no subject line.

Expected results:

It should have opened a new compose window but with the recipients address pre-filled and the correct subject line set. It also should have chosen the right identity/account to answer the mail (the account it was received by).

Any chance you can provide a mailto link which triggers this bug consistently for you? Or is it all mailto links? I'm wondering if the link might have been malformed in some way. Even if it was not, I just checked and it's definitely not happening on all mailto links. So we need a test case to have any hope of finding the issue.

You shouldn't have to copy the exact link from the email, hopefully the bug still happens if you obfuscate the address a little.

Sorry for not being specific enough: It definitely happens to all mailto-links. I already tried with several different mailto-links in several different mails across multiple accounts configured.
After re-starting multiple times the behavior however changed. It still does not learn subject and recipient but it configures the identity/account for the reply correctly to be set to whatever account the original mail was from.

Let me know if I can give you any more information.

OK, I definitely can't reproduce that on Thunderbird 102.0 on Windows 10. I sent myself an email with a mailto link and it works fine.

1. Can you test this issue using a brand new profile? Should be pretty quick to do, just set up one existing account there and click a mailto link in one of your emails.

2. What platform is this on? (Win10/Mac/etc)

Hello, thank you for taking the time to assess my bug report #1778046. I had actually also searched the DB to see if there was a similar case already, but did not find it. However, I would already confirm that it is the same problem.

The hint with sending an email with mailto link is good. With this I can also reproduce a minimal version of the problem here:

1. new e-mail
2. enter recipient address (my own)
3. in the e-mail body: insert link: Text: "test" Link address: "mailto:test@example.com"
4. send
5. wait for the mail to arrive
6. open the mail
7. click on the "test" link
8. Compose window opens, To address is not set to "test@example.com" as expected, but is empty.

I can reproduce the problem at the moment on a Windows 11 system with Thunderbird 102 with an existing profile migrated from an earlier Thunderbird version.

I also tested again right away with a new profile without any addons installed. To my surprise, it works as expected. So it seems to be my profile or an addon. I will at least deactivate the addons again step by step and hope that I can narrow it down.

(In reply to Matthias Petermann from comment #5)

I also tested again right away with a new profile without any addons installed. To my surprise, it works as expected. So it seems to be my profile or an addon. I will at least deactivate the addons again step by step and hope that I can narrow it down.

Thank you for the thorough testing help!

Ok, the problem still occurs with the migrated profile even if I disable all addons.

With the newly created profile it works.

What steps could I take to investigate this further? The profile has been around for a very long time and has had a few migrations. It's not a huge amount of work to recreate it completely - but then the bug (if it is one) would also be unsolved.

(In reply to Matthias Petermann from comment #7)

What steps could I take to investigate this further? The profile has been around for a very long time and has had a few migrations. It's not a huge amount of work to recreate it completely - but then the bug (if it is one) would also be unsolved.

Agreed, we'd appreciate further investigation. At this point, I think it'd be good to take a look at the modified preferences. If you go to Settings and search "Config Editor" you'll find the button that will take you to the advanced config editor. There is a checkbox there to show only "modified preferences".

Check that, and then highlight(right click "Select All") and copy paste all the preferences. You can add them in this bug as an attachment. There are sometimes things in there that you may not want public, like account names and certain folder names. If you want to take them out, do so, it's doubtful they're relevant.

If you're not comfortable putting that information here, also fine, you can mail it to me at sancus at thunderbird net and I can take a look.

4. send

Instead of sending, can you save it as a draft, then export the draft to an .eml, then upload the .eml file here?

Can you also check the mailto link is rendered correctly? Open DevTools, inspect the mailto link in the draft (in the message pane, not in the compose window), paste the whole <a> element or the href attribute here, thanks.

(In reply to Andrei Hajdukewycz [:sancus] from comment #8)

Check that, and then highlight(right click "Select All") and copy paste all the preferences. You can add them in this bug as an attachment. There are sometimes things in there that you may not want public, like account names and certain folder names. If you want to take them out, do so, it's doubtful they're relevant.

If you're not comfortable putting that information here, also fine, you can mail it to me at sancus at thunderbird net and I can take a look.

Hello Andrei, thank you for your assistance. I have extracted the changed configuration parameters, masked the sensitive information and attached it directly to the ticket. I hope you can do something with it. If you have any questions, I'm happy to help.

(In reply to Ping Chen (:rnons) from comment #9)

4. send

Instead of sending, can you save it as a draft, then export the draft to an .eml, then upload the .eml file here?

Can you also check the mailto link is rendered correctly? Open DevTools, inspect the mailto link in the draft (in the message pane, not in the compose window), paste the whole <a> element or the href attribute here, thanks.

Hello Ping, the link element looks like this:

<a moz-do-not-send="true" href="mailto:test@example.com">Test</a>

I also exported as you described a draft of the email that results from clicking the mailto link in the compose window as an .eml file.

Oh, I meant exporting the draft containing the mailto link. But your href looks correct, let's do another test. In DevTools > Console, run

MailServices.compose.OpenComposeWindowWithURI(null, Services.io.newURI('mailto:test@example.com'), null)

should open a compose window with to set to test@example.com, let me know your result

Hello, thank you for the tip. I find it interesting that Thunderbird can be controlled in this way. My experiences with it are outdated and still come from the XUL time ;-) Is this the same interface that a Thunderbird plugin would use? And is it possible to trigger this interface from "outside", i.e. when the Thunderbird process is not started yet? But that's just by the way - if there is a good documentation about this I would be very happy about a link.

To the actual topic... when I execute the command in the console I get an empty compose window. The to address is also empty.

If you go to Tools -> Developer Tools -> Error Console and click on a mailto link, does it produce any new error message? (the trash icon can be used to clear out irrelevant stuff before you test).

I'll give the prefs a look through later today but it could take some time to figure out if there's anything in there.

(In reply to Andrei Hajdukewycz [:sancus] from comment #3)

OK, I definitely can't reproduce that on Thunderbird 102.0 on Windows 10. I sent myself an email with a mailto link and it works fine.

1. Can you test this issue using a brand new profile? Should be pretty quick to do, just set up one existing account there and click a mailto link in one of your emails.

Using a "brand new" version of Thunderbird, so just creating a new empty profile with standard settings, I can't reproduce the bug.
So I am also at the point, it's not that kind of a big deal to "re do" all the settings and stuff, it's just annoying.
Still this wouldn't fix the underlying issue that Thunderbird does not recognize part of the mailto-information.

2. What platform is this on? (Win10/Mac/etc)
   Currently Win10 but I have some Linux/fedora machines, I just haven't had time to update to the latest Thunderbird there. So it's Win10 only for me.

Anyway: I already noticed that restarts of Thunderbird "fixes" at least some of the functionality. I restarted several times, then it started to use the right mail account to answer but still didn't fill in the recipient. Now after another restart it also uses the wrong account again.

Sorry that I am respon(In reply to Ping Chen (:rnons) from comment #14)

Oh, I meant exporting the draft containing the mailto link. But your href looks correct, let's do another test. In DevTools > Console, run

MailServices.compose.OpenComposeWindowWithURI(null, Services.io.newURI('mailto:test@example.com'), null)

should open a compose window with to set to test@example.com, let me know your result

I should've read through the whole thread at first, sorry for double-posting:
I can also confirm that executing your javascript code inside the DevConsole opens a compose window - but an empty one without recipient.

I guess Services.io.newURI('mailto:test@example.com').QueryInterface(Ci.nsIMailtoUrl) throws error for you?

(In reply to Ping Chen (:rnons) from comment #19)

I guess Services.io.newURI('mailto:test@example.com').QueryInterface(Ci.nsIMailtoUrl) throws error for you?

not sure if XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), spec: Getter, prePath: Getter, scheme: Getter, userPass: Getter, username: Getter, password: Getter, hostPort: Getter, host: Getter, port: Getter, … } really is an Error, at least I can't see that it's wrong. But that's the response I get upon running the query.

It's not an error, one more test please.

params = Cc["@mozilla.org/messengercompose/composeparams;1"].createInstance(Ci.nsIMsgComposeParams);
fields = Cc["@mozilla.org/messengercompose/composefields;1"].createInstance(Ci.nsIMsgCompFields);
fields.to = "a@b.c"
params.composeFields = fields
MailServices.compose.OpenComposeWindowWithParams(null, params)

(In reply to Ping Chen (:rnons) from comment #21)

It's not an error, one more test please.

[....]

This opens the window but without recipient address again, at least for me.

(In reply to Ping Chen (:rnons) from comment #21)

It's not an error, one more test please.

params = Cc["@mozilla.org/messengercompose/composeparams;1"].createInstance(Ci.nsIMsgComposeParams);
fields = Cc["@mozilla.org/messengercompose/composefields;1"].createInstance(Ci.nsIMsgCompFields);
fields.to = "a@b.c"
params.composeFields = fields
MailServices.compose.OpenComposeWindowWithParams(null, params)

Hello, thanks for the ongoing support in this case and sorry for my late answer. I did perform the test and can confirm the result of duckzill0r. In my case also a window without recipient address is opened.

This is the console dialog with some warning messages:

params = Cc["@mozilla.org/messengercompose/composeparams;1"].createInstance(Ci.nsIMsgComposeParams);
XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), type: Getter & Setter, format: Getter & Setter, originalMsgURI: Getter & Setter, identity: Getter & Setter, composeFields: Getter & Setter, bodyIsLink: Getter & Setter, sendListener: Getter & Setter, smtpPassword: Getter & Setter, origMsgHdr: Getter & Setter, … }

fields = Cc["@mozilla.org/messengercompose/composefields;1"].createInstance(Ci.nsIMsgCompFields);
XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), getHeader: getHeader(), hasHeader: hasHeader(), getUnstructuredHeader: getUnstructuredHeader(), getAddressingHeader: getAddressingHeader(), getRawHeader: getRawHeader(), headerNames: Getter, buildMimeText: buildMimeText(), setHeader: setHeader(), deleteHeader: deleteHeader(), … }

fields.to = "a@b.c"
"a@b.c"

params.composeFields = fields
XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), getHeader: getHeader(), hasHeader: hasHeader(), getUnstructuredHeader: getUnstructuredHeader(), getAddressingHeader: getAddressingHeader(), getRawHeader: getRawHeader(), headerNames: Getter, buildMimeText: buildMimeText(), setHeader: setHeader(), deleteHeader: deleteHeader(), … }

MailServices.compose.OpenComposeWindowWithParams(null, params)
undefined

Diese Seite befindet sich im Kompatibilitätsmodus (Quirks). Das Seitenlayout kann beeinflusst werden. Verwenden Sie für den Standardmodus "<!DOCTYPE html>".
blank
window.controllers/Controllers sollte nicht mehr verwendet werden. Verwenden Sie es nicht für die Browser-Erkennung. blank
Diese Seite befindet sich im Kompatibilitätsmodus (Quirks). Das Seitenlayout kann beeinflusst werden. Verwenden Sie für den Standardmodus "<!DOCTYPE html>".
blank
Diese Seite befindet sich im Kompatibilitätsmodus (Quirks). Das Seitenlayout kann beeinflusst werden. Verwenden Sie für den Standardmodus "<!DOCTYPE html>".
MsgComposeCommands.js:10499:14
Diese Seite befindet sich im Kompatibilitätsmodus (Quirks). Das Seitenlayout kann beeinflusst werden. Verwenden Sie für den Standardmodus "<!DOCTYPE html>".
MimeMessage.jsm:621:24

After executing the code in comment 21, click the button on the top-right and select .../messengercompose/messengercompose...

Run gMsgCompose.compFields.to. If it's correct, run ComposeFieldsReady(), then go to the compose window to check the to field

(In reply to Ping Chen (:rnons) from comment #24)

Created attachment 9284429 [details]
inspect_messengercompose_window

After executing the code in comment 21, click the button on the top-right and select .../messengercompose/messengercompose...

Run gMsgCompose.compFields.to. If it's correct, run ComposeFieldsReady(), then go to the compose window to check the to field

Hello, I have tested this once right away:

>> gMsgCompose.compFields.to
<- ""
>> ComposeFieldsReady()
<- undefined
>> gMsgCompose.compFields.to="test@example.com"
<- "test@example.com"
>> ComposeFieldsReady()
<- undefined

As you can see, compField.to is empty at first and also in the Compose window the field is empty. After I set the compField.to manually and call ComposeFieldsReads() again, the field is set in the existing Compose window. This also works repeatedly.

(In reply to Matthias Petermann from comment #25)

[...]
As you can see, compField.to is empty at first and also in the Compose window the field is empty. After I set the compField.to manually and call ComposeFieldsReads() again, the field is set in the existing Compose window. This also works repeatedly.

I can confirm this behavior. gMsgCompose.compFields.to is first set to "".
So running ComposeFieldsReady()changes nothing. After setting gMsgCompose.compFields.to="a.b@c.de" and running ComposeFieldsReady() the "To"-Field is fine and set to the specified value.

OK, one more test. This time click the Write button to open an empty compose window. Inspect the compose window in DevTools, run

params = Cc["@mozilla.org/messengercompose/composeparams;1"].createInstance(Ci.nsIMsgComposeParams);
fields = Cc["@mozilla.org/messengercompose/composefields;1"].createInstance(Ci.nsIMsgCompFields);
fields.to = "a@b.c"
params.composeFields = fields 
gMsgCompose = MailServices.compose.initCompose(params, null, null)

Tell me the result of

gMsgCompose.compFields.to 

The above snippet is similar to https://searchfox.org/comm-central/rev/eaf2050281156524b657cb0b7c87645c377d454f/mail/components/compose/content/MsgComposeCommands.js#4417-4421, initCompose should call https://searchfox.org/comm-esr91/rev/83b2f2b16fcbed289bfd0d5b09f386245fa5e749/mailnews/compose/src/nsMsgCompose.cpp#1485 to init the compFields member.

(In reply to Ping Chen (:rnons) from comment #27)

Tell me the result of

gMsgCompose.compFields.to 

 ->> gMsgCompose.compFields.to
 <<- a@b.c

So this variable/field now contains the information a@b.c, yes.

Sorry, double posting again, but forgot to mention: it's only the variable set. The "to"-field in the compose window still remains empty.
I just ran ComposeFieldsReady() to verify if it updates. Yes it does, but it throws an error
Uncaught TypeError: gMsgCompose.editor is null updateEditableFields chrome://messenger/content/messengercompose/MsgComposeCommands.js:472

(In reply to duckzill0r from comment #29)

->> gMsgCompose.compFields.to
<<- a@b.c

So this variable/field now contains the information `a@b.c`, yes.

Combine this with comment 25, seems MailServices.compose.initCompose was not called on your machines. An error may have happened in MsgComposeCommands.js before https://searchfox.org/comm-central/rev/eaf2050281156524b657cb0b7c87645c377d454f/mail/components/compose/content/MsgComposeCommands.js#4417-4421

by the way: I just ran mozregression (because it was mentioned in bug 1777683 ) to verify which is the first version this bug appears.
It's indeed 2022-06-13 which (surprisingly or not) is the same build that the other bug first occurs. So it probably is about the same changes/changeset that caused this error.

app_name: thunderbird
build_date: 2022-06-13
build_file: C:\Users\.........\.mozilla\mozregression\persist\2022-06-13--comm-central--thunderbird-103.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-13-09-59-54-comm-central/thunderbird-103.0a1.en-US.win64.zip
changeset: 1a62e2afc99432552fd022db030584a988a4411b
pushlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=c17365dc7e4e34f901c18b54c115e3f788051db3&tochange=1a62e2afc99432552fd022db030584a988a4411b
repo_name: comm-central
repo_url: https://hg.mozilla.org/comm-central

Dear All,

I face the same issue after upgrade to TB 102. It occurs only in windows 11 hosts. When we send emails directly from financial system via mailto protocol it transfers to TB all fields but "To". Attachment is being transferred to TB as well as subject field. Nevertheless, it is an inconvenience for users to type in email address "To" manually.

Can the support team share if the root cause has been found already? In case not, can I help somehow?
If the root cause has been known, can you please share approx. date when the fix will be released?

Best regards,
Marcin

I'd like to propose elevating priority of this issue. Please consider invoices and other documents send from third party software e.g. financial systems. This is a substantial number of activities in case of manual manual retyping email addresses.

Thank you for the consideration.

(In reply to duckzill0r from comment #32)

by the way: I just ran mozregression (because it was mentioned in bug 1777683 ) to verify which is the first version this bug appears.
It's indeed 2022-06-13 which (surprisingly or not) is the same build that the other bug first occurs. So it probably is about the same changes/changeset that caused this error.

If that's the case, this bug is probably a duplicate of bug 1777683.

For those experiencing this one, does disabling E2E on the account prevent this from occurring and provide a temporary workaround?

(In reply to Andrei Hajdukewycz [:sancus] from comment #35)

If that's the case, this bug is probably a duplicate of bug 1777683.

In terms of preventing such regression in the future by executing a manual test plan, it wouldn't be advisable to duplicate this elsewhere. In cases where one solution fixes two bugs, commonly "FIXED by bug xxx" is used in the second bug with the same target milestone.

(In reply to Andrei Hajdukewycz [:sancus] from comment #35)

For those experiencing this one, does disabling E2E on the account prevent this from occurring and provide a temporary workaround?

Well, for me - me being the one who reported this here and did some of the research on bug 1777683 - disabling E2E fixed this.

(On Windows 10, if Marcin is only experiencing this on Win11 hosts and not on Win10 hosts with E2E enabled and all the same profiles we might see the same - or another feature/bug).

We use S/MIME certificates to sign our emails by default (we do not encrypt by default). I've just tested switching off this functionality. I confirm that this is a work around. It helps in my case. It also fixes bug 1778898 which I have opened.

(In reply to Marcin Szczesny from comment #38)

We use S/MIME certificates to sign our emails by default (we do not encrypt by default). I've just tested switching off this functionality. I confirm that this is a work around. It helps in my case. It also fixes bug 1778898 which I have opened.

Hi Marcin, what exactly did you do to turn off the function? I would also like to test or confirm your workaround with me - but so far I haven't found a global on/off switch for (temporarily) turning it off. Thanks, Matthias

(In reply to Matthias Petermann from comment #39)

(In reply to Marcin Szczesny from comment #38)

We use S/MIME certificates to sign our emails by default (we do not encrypt by default). I've just tested switching off this functionality. I confirm that this is a work around. It helps in my case. It also fixes bug 1778898 which I have opened.

Hi Marcin, what exactly did you do to turn off the function? I would also like to test or confirm your workaround with me - but so far I haven't found a global on/off switch for (temporarily) turning it off. Thanks, Matthias

Hi Matthias,

In Account Settings within End-To-End Encryption section, when you clear (remove assigned) s/mime certificates the functionality is being switched off. Of course you need take in to account PGP keys as well (we don't use PGP at all).

(In reply to Marcin Szczesny from comment #40)

(In reply to Matthias Petermann from comment #39)

(In reply to Marcin Szczesny from comment #38)

We use S/MIME certificates to sign our emails by default (we do not encrypt by default). I've just tested switching off this functionality. I confirm that this is a work around. It helps in my case. It also fixes bug 1778898 which I have opened.

Hi Marcin, what exactly did you do to turn off the function? I would also like to test or confirm your workaround with me - but so far I haven't found a global on/off switch for (temporarily) turning it off. Thanks, Matthias

Hi Matthias,

In Account Settings within End-To-End Encryption section, when you clear (remove assigned) s/mime certificates the functionality is being switched off. Of course you need take in to account PGP keys as well (we don't use PGP at all).

Thank you! That worked and I can confirm that this also works for me as a workaround. Not ideal, but at least a temporary solution to be able to work reasonably.

A big thank you to everyone for the tips, interesting insights, and solution to the problem. I look forward to Thunderbird 104 and can live with the workaround until then. Just out of interest - is the ticket linked to a git repo where you could take a look at the change to this ticket?

Not a git repo, just the normal mozilla hg repo. https://hg.mozilla.org/comm-central/rev/bf171cfffec9 (see bug 1777683)