Skip to content
jph-sendlater edited this page Apr 23, 2021 · 4 revisions

WebExtension migration roadmap

The ongoing goal is to transition all experimental Send Later functionality to its official webextension counterparts. However, for the time being there are major components of Send Later with no suitable alternatives. In order to ease the transition, the medium-term goal is restructuring send later to be as webextension-like as possible. This will ensure minimal changes will be required to adapt as new API's become available.

There are several types of tasks that can move Send Later towards that goal:

Align experiments with WebExt API's. For example,

  • Communicate between background context and experiments using the webextension-style ephemeral id's (with context objects like extension.messageManager.*).

Remove all application-specific logic in privileged contexts. For example,

  • Register event listeners to request data handling be carried out in background context wherever possible.

De-duplicate existing functionality by using existing API's. As more API's are added to Thunderbird this list will expand, but there are already a couple of candidate functions with viable WebExtension alternatives. Notably:

  • Alerts and prompts can be handled with popup windows using messenger.windows.create
  • Deleting messages is possible via messenger.messages.delete
  • Enumerating pending messages can be handled in the background context using the messenger.messages API. This was actually implemented early on, but issues related to #16 forced me to revert to experiment code. Those bugs are fixed in Thunderbird v88, so it will soon be possible to migrate back to the future, but those changes will have to wait until the next ESR.

Note on backwards-compatibility

Send Later development will only target Thunderbird's ESR release version, while establishing forward-compatibility with the beta channel. Each time a new ESR version is released I intend to replace experiment code with new WebExtension API's wherever possible, removing vestigial legacy code in the process. This will typically result in backwards-incompatibility unless those API's have been back-ported. Any time that happens, Send Later's major version will bump, and the previous version's branch will only receive critical bug fixes.

Clone this wiki locally