Take advantage of Bug 1824976 and use "thunderbird ext+thunderlink:something" for the WebExtension protocol handler support from the command line

[jobisoft]

Hi,

in the past months, we have fixed Thunderbird's protocol handler support for WebExtensions. Today, my last patch of this effort landed, which enabled access from the command line.

First registers a handler like so:

{
        "manifest_version": 2,
        "name": "thunderlink",
        "version": "0.1",
        "protocol_handlers": [{
                "protocol": "ext+thunderlink",
                "name": "Thunderlink Protocol Handler,
                "uriTemplate": "/thunderlink.html#%s"
        }]
}

Now Thunderbird supports the url scheme ext-thunderlink: and if it is used in a popup or tab, it will be passed on to the registered html file with the original url replacing the %s placeholder in the registration. Your html file (or better its loaded script) can now do whatever you need to do (decode the payload and open the correct message and close the handler tab).

With Bug 1824976 landed (maybe in tomorrows Daily already), this can also be invoked from the command line:

thunderbird ext+thunderlink:<payload-data>

I think this may remove a lot of the extra steps you currently have to do to get the OS integration working. I assume, you can turn thunderlink now into a pure WebExtension.

[jobisoft]

For opening the message you can use browser.messageDisplay.open()

https://webextension-api.thunderbird.net/en/stable/messageDisplay.html#open-openproperties

[CamielBouchier]

Hi John,

Thanks for the notification.

I will have a look, but as I am in acute shortage of time, that might be considerably later ...

Moreover, as now all actually works well, stable and documented there isn't an immediate need or drive to change.

Camiel B.

[jobisoft]

Sure, ping whenever you need help: https://developer.thunderbird.net/add-ons/community

I think I read that MacOS integration is not fully working with your current approach?

We will also increase our push to remove Experiments from add-ons, when there are not needed, to improve overall stability and user experience (they are quite unhappy with the "do all you want on my computer" permission, Experiment add-ons have to request.

[CamielBouchier]

Hi,

in the past months, we have fixed Thunderbird's protocol handler support for WebExtensions. Today, my last patch of this effort landed, which enabled access from the command line.

First registers a handler like so:

{
        "manifest_version": 2,
        "name": "thunderlink",
        "version": "0.1",
        "protocol_handlers": [{
                "protocol": "ext+thunderlink",
                "name": "Thunderlink Protocol Handler,
                "uriTemplate": "/thunderlink.html#%s"
        }]
}

Now Thunderbird supports the url scheme ext-thunderlink: and if it is used in a popup or tab, it will be passed on to the registered html file with the original url replacing the %s placeholder in the registration. Your html file (or better its loaded script) can now do whatever you need to do (decode the payload and open the correct message and close the handler tab).

With Bug 1824976 landed (maybe in tomorrows Daily already), this can also be invoked from the command line:

thunderbird ext+thunderlink:<payload-data>

I think this may remove a lot of the extra steps you currently have to do to get the OS integration working. I assume, you can turn thunderlink now into a pure WebExtension.

Hi John,

I was having a quick look into this, but I don't get it. Do you have somewhere an example indicating where this sits and how it is supposed to work? I am just an occasional thunderbird api user that developed thunderlink with much examples, using pre-existing code, trial and error ... until it worked reliably and stable. Not familiar with all the ins and outs of this thunderbird api's and all of the fiddling around it ...

Camiel B

[jobisoft]

Hi,

install this extension (not as temporary): protocol_handler.zip

It registers the ext+thunderlink: url handler.

You can now call this

thunderbird.exe ext+thunderlink:CamielBouchier/cb_thunderlink/issues/55/[email protected]

The headerMessageId given is the id of the last message I have received from you, do not know if it exists on your system, maybe you need to use a different id for the test.

The add-on extracts the id from the ext+thunderlink: url and throws it onto messageDisplay.open() to open it.

You can of course use a different payload, with additional data (I think you base64 encode your id with additional data like subject or sender, but I checked long ago and do not fully remember). To find the message, you can then use browser.messages.query() and throw the returned messageId onto messageDisplay.open().

This works with both, Thunderbird already running and Thunderbird not already running.

[CamielBouchier]

Hi, I think I have the idea ... 2 questions though:

• what is the minimal thunderbird version on which this works? On my installation (102.10.0) it seems to do nothing.
• does it require anything else to be registered in the os or is thunderbird taking care of all?

[jobisoft]

That feature has been added to Thunderbird Beta 113. So this is something for your next version which will be compatible with the next ESR released in summer (Thunderbird Supernova 115). It will not be backported to Thunderbird 102.

Regarding the OS integration: The protocol_handler is only registered within Thunderbird, not the OS. If you point these customs urls to Thunderbird (or use it on the command line), then Thunderbird knows what to do with it. But your OS will not know that ext+thunderlink: should be opened in Thunderbird, the user has to set that up on its own.

Are there use-cases, where such a link appears outside of Thunderbird (in Firefox/Chrome?) and the user wants to click on it and it should open Thunderbird?

[CamielBouchier]

Thanks, got it.

Current architecture is https://camiel.bouchier.be/en/cb_thunderlink/architecture and I think this approach removes potentially process 2 and process 3.

Yes, there are instances this is called from firefox/chrome/ some even from emacs. But that's thus all a matter of registering in the OS (the installation process in my architecture).

Even though your approach looks to be the better one on the mid term, I am not going to implement it too fast either, for a number of reasons:

1. My time is limited ;)
2. Current set-up works very well and is decently debugged
3. As long as the majority of users has not switched to 115, I will need to maintain 2 ...

[jobisoft]

Full Ack. Just wanted to make you aware of it. If you have questions, do not hesitate to reach out.

A scenario I had in mind: Some internal function you need may have changed in 115 or may no longer work and instead of trying to fix the old legacy approach, you could switch to this for 115.

Edit: You are using native messaging to get into TB, which most probably has not changed.