1724292 - Clicking mid: URLs in calendar entries no longer opens mails, which makes Message -> Convert To > Event useless UX

Status: RESOLVED FIXED

(Calendar :: Dialogs, defect, P2)

Description

[Harald van Dijk]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

In Thunderbird 90.0b3, I started using the very nice feature where you right-click e-mails, choose "Convert To", then "Event...", and it gives you a calendar entry with a mid: URL, where clicking that mid: URL from the calendar entry opens the original mail. This appears to be a recent new feature (bug 1706158), and it is a very welcome one. After upgrading to Thunderbird 91.0b6, this no longer works.

Steps to reproduce, in Thunderbird 91.0b6:

1: Use "Convert To", "Event..." to create a calendar entry.
2: In the event dialog, notice the "Related Link:" label and "mid:[...]" link to its right. Click the link.

Actual results:

Nothing happens.

Expected results:

The linked mail should open.

Comment 1

[Geoff Lankow (:darktrojan) [PTO, back 8 Dec]]

Quite likely to be bug 1723643, but it's interesting that you say it used to work and now doesn't. AFAICT, the code was written but never actually shipped.

Comment 2

[Harald van Dijk]

I would think from that bug that mid: URLs don't work at all, but they appear to work even in Thunderbird 91.0b6 in other cases. The message ID for the notification I got for that comment was [e-mail], so I tried running thunderbird mid:[e-mail], and that opened the message.

Comment 3

[Thomas D. (:thomas8)]

This also fails on 92.0a1 (2021-08-04) (64-bit), and (2021-08-05).

https://searchfox.org/comm-central/rev/26185cafc5c5c67d84c0cec98bd8c6397dfefdb0/calendar/base/src/calApplicationUtils.js#9-43
launchBrowser() is called, but does seem not do anything.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Harald van Dijk from comment #2)

I would think from that bug that mid: URLs don't work at all, but they appear to work even in Thunderbird 91.0b6 in other cases. The message ID for the notification I got for that comment was [e-mail], so I tried running thunderbird mid:[e-mail], and that opened the message.

Indeed, that works on 91.0b6 (64-bit).

Comment 5

[Thomas D. (:thomas8)]

Confirming for 92.0a1 (2021-08-05) (64-bit), win10.

For (enterprise) users who rely on the workflow of Convert-msg-to-Event, this will be a significant fallout, hence P2/S2.

In terms of UX, this makes converting email messages into events all but a no-op, because you'll have a dead link in the calendar event, hence no information from the message except the subject, as we no longer put the message text into event description. Btw, is that a bug, or intentional?

The related bugs history is a bit nested, but iiuc, Daily 92.0a1 (2021-08-05) should have everything, and I have verified that MidProtocolHandler.jsm is present. In spite of that, clicking on the link in the calendar event summary does nothing.

First we should remove the command event handler which does nothing on the XUL <label>. Which means that the link is currently not keyboard accessible. Why are we using a XUL <label> element for a link?

https://searchfox.org/comm-central/rev/26185cafc5c5c67d84c0cec98bd8c6397dfefdb0/calendar/base/content/widgets/calendar-item-summary.js#295-297

      urlLink.addEventListener("command", event => {
        launchBrowser(urlLink.getAttribute("href"), event);
      });

The identical click handler triggers when clicked, launchBrowser() is correctly called, but it fails to open the mid: link.

Comment 6

[Harald van Dijk]

(In reply to Thomas D. (:thomas8) from comment #5)

In terms of UX, this makes converting email messages into events all but a no-op, because you'll have a dead link in the calendar event, hence no information from the message except the subject, as we no longer put the message text into event description. Btw, is that a bug, or intentional?

In 91.0b6, the message text does show up in the event description. If that does not happen in 92, I would raise that as a bug: even if the mid: links are made to work again: those links are only usable in Thunderbird, not in external software that accesses the same calendars, so the calendar events are still much less useful than they could be.

Comment 7

[Magnus Melin [:mkmelin]]

Thunderbird registers as the mid: protocol handlers. So calls from anywhere in the system can open the message in Thunderbird.

Comment 8

[Harald van Dijk]

This worked in 91.0b5 and broke in 91.0b6. Looking at the diff between the two versions, I noticed this bit that looked suspicious:

--- thunderbird-91.0b5/comm/mail/app/profile/all-thunderbird.js
+++ thunderbird-91.0b6/comm/mail/app/profile/all-thunderbird.js
@@ -384,6 +384,29 @@
 pref("network.protocol-handler.warn-external.https", false);
 pref("network.protocol-handler.warn-external.ftp", false);
 
+// prevent web pages from registering mailnews protocol handlers
+pref("network.protocol-handler.external.cid", false);
+pref("network.protocol-handler.external.mid", false);
+pref("network.protocol-handler.external.mailto", false);
+pref("network.protocol-handler.external.imap", false);
+pref("network.protocol-handler.external.imap-message", false);
+pref("network.protocol-handler.external.pop", false);
+pref("network.protocol-handler.external.pop3", false);
+pref("network.protocol-handler.external.mailbox", false);
+pref("network.protocol-handler.external.mailbox-message", false);
+pref("network.protocol-handler.external.smtp", false);
+pref("network.protocol-handler.external.smtps", false);
+pref("network.protocol-handler.external.nntp", false);
+pref("network.protocol-handler.external.news", false);
+pref("network.protocol-handler.external.news-message", false);
+pref("network.protocol-handler.external.snews", false);
+pref("network.protocol-handler.external.ldap", false);
+pref("network.protocol-handler.external.ldaps", false);
+pref("network.protocol-handler.external.webcal", false);
+pref("network.protocol-handler.external.webcals", false);
+pref("network.protocol-handler.external.moz-cal-handle-itip", false);
+pref("network.protocol-handler.external.smile", false);
+
 pref("network.hosts.smtp_server",           "mail");
 pref("network.hosts.pop_server",            "mail");

And indeed, after setting network.protocol-handler.external.mid to true in 91.0b6, the links work again.

Comment 9

[Stefan Sitter [:ssitter]]

Related to Bug 1723643?

Comment 10

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: With pref `network.protocol-handler.external.mid = true`, TB asks to choose app for opening mid: links

(In reply to Harald van Dijk from comment #8)

+++ thunderbird-91.0b6/comm/mail/app/profile/all-thunderbird.js
+// prevent web pages from registering mailnews protocol handlers
+pref("network.protocol-handler.external.mid", false);
And indeed, after setting network.protocol-handler.external.mid to true in 91.0b6, the links work again.

Thanks much Harald for investigating, that's valuable information. What exactly happened after you first clicked on a mid: link after enabling the pref?

For me, changing the pref causes TB to ask which app should handle mid: protocol links (see screenshot), so it's not just working again but needs more non-trivial user input. This hint is probably going in the right direction, but it doesn't look like a sufficient fix to me yet.
Looks like we're not succeeding to register ourselves for handling mid: protocol.
Or maybe one of my other installations overwrote that?

Creating and setting the other related pref, network.protocol-handler.expose.mid = true did not seem to have any effect, with or without the ...external.mid pref set.
https://support.mozilla.org/en-US/questions/1005638

Comment 11

[Harald van Dijk]

(In reply to Thomas D. (:thomas8) from comment #10)

(In reply to Harald van Dijk from comment #8)

+++ thunderbird-91.0b6/comm/mail/app/profile/all-thunderbird.js
+// prevent web pages from registering mailnews protocol handlers
+pref("network.protocol-handler.external.mid", false);
And indeed, after setting network.protocol-handler.external.mid to true in 91.0b6, the links work again.

Thanks much Harald for investigating, that's valuable information. What exactly happened after you first clicked on a mid: link after enabling the pref?

For me, changing the pref causes TB to ask which app should handle mid: protocol links (see screenshot),

Right, that rings a bell. I did not see that in 91.0b6, but I think that came up in 90.0b3 and I had chosen "Always use this application" in that version already. When I then changed the pref in 91.0b6, Thunderbird would have still remembered that setting, so the prompt did not show up again and I forgot about it. It makes sense that it does show up for you if it's the first time for you clicking a mid: link.

Comment 12

[Magnus Melin [:mkmelin]]

Ping, any insight into whether we should set network.protocol-handler.external.mid true, or is there some other fix?

Comment 13

[Ping Chen [:rnons] (away)]

Seems we need to set network.protocol-handler.external.mid to true, the "choose application" dialog is expected, it's similar to paste the mid url to firefox, and firefox will show a "choose application" dialog as well.

But I guess it's possible to register mid the same way as mailto, will investigate. Also maybe related, mailto links in event description don't work as well.

Comment 14

[Harald van Dijk]

Unfortunately it turns out network.protocol-handler.external.mid doesn't fix it on all platforms anyway. I tested what happens on Windows and found that setting the pref to true does result in that "Choose Application" window, but the mail does not get opened even when Thunderbird is picked to open the link.

Comment 15

[Ben Bucksch (:BenB)]

Have you tried just deleting the preference entirely, with no value, neither true nor false? The code is complicated, and there are at least 4 consumers of this pref. If the pref is not set, some code defaults to "external-default" pref, which is default true, some defaults to false.

If this started to break a few days ago, that's likely due to bug 1717042, and then removing the pref (no value at all) should revert it to the previous state. FWIW, there was no specific reason that we set mid = true, other than bug 1717042 comment 15. So, I would just remove that one line for mid again and leave mid pref undefined, to revert to the previous state.

Comment 16

[Ben Bucksch (:BenB)]

I.e. in the code, simply remove this line from comm/mail/app/profile/all-thunderbird.js:
pref("network.protocol-handler.external.mid", false);

Comment 17

[Harald van Dijk]

(In reply to Ben Bucksch (:BenB) from comment #16)

I.e. in the code, simply remove this line from comm/mail/app/profile/all-thunderbird.js:
pref("network.protocol-handler.external.mid", false);

That's more difficult with binary releases, and my system is not set up for building for Windows. I tried updating the binary release's omni.ja's defaults/pref/all-thunderbird.js the way you suggested on Windows, and confirmed that the config editor no longer shows the pref. It has the same effect as setting the pref to true: the "Choose Application" window shows up, but choosing Thunderbird does not open the linked mails.

(Note that this Windows problem may not be a regression. I only know for sure that things worked in 90.0b3 on Linux, not on any other platform.)

Comment 18

[Stefan Sitter [:ssitter]]

(In reply to Stefan Sitter [:ssitter] from comment #9)

Related to Bug 1723643?

I'm no expert but did anyone actually verify that MidProtocolHandler.jsm not being shipped in Thunderbird 91 is not the root cause for mid protocol not working in Thunderbird 91? I.e it is still broken after adding MidProtocolHandler.jsm to Thunderbird 91?

Comment 19

[Ping Chen [:rnons] (away)]

It's complicated, but MidProtocolHandler.jsm is not related to this bug, will make a fix soon.

Comment 20

[Ping Chen [:rnons] (away)]

Attachment: Bug 1724292 - Open mid url internally in calApplicationUtils.js. r=mkmelin

This fixes the related mid link of calendar event/task. Open mid url externally has three problems:

1. TB has to be set as the default mail app
2. a "Choose Application" dialog is shown
3. somehow doesn't work on Windows

This patch moves openMessageByMessageId into MailUtils.jsm to be reused.

Comment 21

[Ping Chen [:rnons] (away)]

Attachment: Bug 1724292 - Open mid urls in mail messages internally. r=mkmelin

This avoids the same problems as described in D122316, but for mid urls in a mail message.
Depends on D122316.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/34a5219c1deb
Open mid url internally in calApplicationUtils.js. r=mkmelin
https://hg.mozilla.org/comm-central/rev/aea151e0f372
Open mid urls in mail messages internally. r=mkmelin

Comment 23

[Ping Chen [:rnons] (away)]

Comment on attachment 9235736 [details]
Bug 1724292 - Open mid urls in mail messages internally. r=mkmelin

Request for the two patches.
[Approval Request Comment]
Regression caused by (bug #): was implemented as opening mid urls externally
User impact if declined: calendar event's related mid link doesn't work
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): low, doesn't work anyway

Comment 24

[Wayne Mery (:wsmwk)]

Comment on attachment 9235736 [details]
Bug 1724292 - Open mid urls in mail messages internally. r=mkmelin

[Triage Comment]
approved for beta

Comment 25

[Rob Lemley [:rjl]]

Thunderbird 92.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/97415809843f
https://hg.mozilla.org/releases/comm-beta/rev/4b67163eabee

Comment 26

[Wayne Mery (:wsmwk)]

Comment on attachment 9235736 [details]
Bug 1724292 - Open mid urls in mail messages internally. r=mkmelin

[Triage Comment]
Approved for esr91

Comment 27

[Rob Lemley [:rjl]]

Thunderbird 91.0.2:
https://hg.mozilla.org/releases/comm-esr91/rev/18c352ede56a
https://hg.mozilla.org/releases/comm-esr91/rev/23f19475e81e