Discussion: How to move forward

[jobisoft]

Hi, this is John from Thunderbird's add-on team. I would like to make a few proposals on how to move forward. I also offer to help to actually implement the proposed changes.

This add-on is still using the Windowlistener API which was created 4 years ago to help add-on devs to make the transition to the new WebExtension technology. With Thunderbird 128, we are no longer supporting the API anymore. While you could update the API on your own, I highly suggest a different path and turn this extension into a pure WebExtension.

From what I can see, the main feature of this add-on is the dropdown selector in the subject line in the message composer. This is not possible with WebExtensions, but we can get very very close: We can add the exact same button (with a menu dropdown) in the toolbar of the message composer:

If this is acceptable, we can convert this extension to a pure WebExtension, reducing your update work to a minimum. This will allow your users to switch to Thunderbird's monthly release channel (the work needed to update your current legacy Extension each month to be compatible with the current release will probably not be feasible).

The next steps would then be the following:

1. Remove unneeded old RDF stuff from the repository.
2. For external contributors it would be ideal if you could remove the necessity to build your add-on (which did not work for me). There is some strange repacking going on, which moves files into a chrome folder. The add-on also cannot be loaded as a temporary add-on, because its ID is not in the manifest, but a placeholder. Replacements in text (like {author}) can remain, but the add-on should run without having to build it, otherwise development will be slowed down enormously.
3. Convert the options page from XUL to HTML and introduce the LegacyPrefs API to keep using the prefs stored in the legacy preference tree. This will be the most time-consuming task.
4. Convert the legacy button and the legacy subject handling logic to pure WebExtenion
5. Rip out the WindowListener API
6. Release a new version for TB 128
7. Migrate the options from the legacy preference tree to the local storage.
8. Release a new version for TB 128
9. Remove the preference migration code and release a pure WebExtension next year

We could file for each task a separate issue to keep track of the work. Looking forward to hearing from you.

[tomaszkrajewski]

For addon usability perspective the best place to locate combo is next to subject field. For me, and other personally known users, it's huge improvement on efficiency.

There was also other way to initiate releases ago -> via suboptions (submenu) under Write message button, but stopped to work some TB updates ago.

No way to inject around subject when working as WebExtension ?

[jobisoft]

Another WebExtion-ish approach (if you do not like the button in the toolbar) would be to have a menu entry in the context menu of the Subject field. But adding a button "somewhere" in the Thunderbird UI is not compatible with the WebExtension framework.

You can remain an Experiment and use the full-access-permission to create the button in the current location, if this really is what your users want. This would change the outlined roadmap and replace the 4th task with creating a dedicated Experiment for the button. But this will require you to continue to manually push updates for each new Thunderbird release (and we are going to release monthly).

The UI interface in the main window could be solved by a context menu entry of the write-message-button. Modifying the existing button is not possible through WebExtension currently. You could also add your own write-message-button which your users can use instead (and let them hide the original one).

[tomaszkrajewski]

1/ I sense that, at least for me, the acceptable solution will be to have dedicated button for new message with prefixes in the messenger window (as you wrote) and context menu on subject and content (as it's now) on message window.
Plus regular button from toolbar for the ones who likes it.

2/ Build process & extra files - for me it takes now 5 secs to build + 30 secs to click in TB to propagate new artifact - years ago TB was having some cache, there was need to restart to be sure that modified files are picked; I'd be happy to move forward, but I need to trust the changes ;). Is there any up to date complete tutorial/guide how to work with development (publicDist, setting the version) ?

[jobisoft]

The way to develop now is to use the temporary install. Go to the add-on manager, select the gear icon and select debug add-ons. There, select to install a temporary add-on. In the opened file picker select the manifest.json file of your project. The add-on will be installed directly, without creating an xpi. You can make changes to your code and just select reload, which will reload your add-on and pick up the changes. I will try to find a more detailed guide. All I have now is

https://developer.thunderbird.net/add-ons/hello-world-add-on

[jobisoft]

FYI: we do not have to make strategic decisions now. For me the most important part is that you are active around here and responsive. Otherwise it would have been risky for me to invest time into actual changes. The work required here is much greater compared to AlertSwitch.

From our discussion in AlertSwitch I learned that you would like to keep some sort of build process for versioning and debugging. Would you be OK with me removing the current build process and you later add a more simplified process back in, or would you like to modify the current code before I start contributing? In order for me to contribute, the source must be hot-loadable. It would be OK for me, if I manually have to replace two or three placeholders (version, debug, ...) to make the source directly runnable, which I do not commit back. But I would like to avoid the building during development.

[tomaszkrajewski]

Today i've spent some time to see AlertSwitch after changes and see how to debug / replace addon. Tommorow I'll conclude your MR & my expectations, then I'd update the build for SubSwitch to let you focus on things where I'm lost.

[tomaszkrajewski]

Please see the updated subswitch repository, for me it worked to temporary load addon from src directory. The build process of the releasable extension lightened a little.

[tomaszkrajewski]

@jobisoft I see that you initiated some activities by cloning the repo. Are you one the subject? How to move forward?

[jobisoft]

Yes, thanks for these changes. I will file a few PRs shortly. The next steps are:

• convert locale files and no longer register them through messenger.WindowListener.registerChromeUrl()
• introduce LegacyPrefs API and no longer use messenger.WindowListener.registerDefaultPrefs()
• convert options page from XUL to HTML and no longer use messenger.WindowListener.registerOptionsPage()

That will be the part which keeps you from moving forward. The next step is then the decision about the UI elements you want to keep using. Reduced comfort but pure WebExtension vs. Experiment code with custom UI elements.

[jobisoft]

PR for the locale files has been filed: #8.

[tomaszkrajewski]

A. Concerning frontend functionality. I believe we need in the message compose window the 2 ways to play 1/ button on toolbar to pick the prefix (as SignatureSwith works) 2/ button under right mouse click over the window (as it's now) + over the message header (as you've proposed)

B. Concerning 'backend' functionality, there is hook on when replying a message to look for the prefix and use this one. I like this feature.

C. As the nice to have, future development, I will try to proceed with the button on the messenger window for new message with already chosen prefix. But for me its future.

How to move forward with A & B ? What about HTML instead of XUL in options & discovery dialogs?

[jobisoft]

It is too early to think about frontend or backend functionality changes. In the end, you will be able to have the same features as now by using Experiments for the parts which are not doable via standard WebExtension APIs. But as I outlined earlier, some things will never become available through WebExtension APIs. Switching to a WebExtension UI entry point could be considered, to reduce your maintenance work, even if that is not a perfect match.

The next big step is converting your options page from XUL to HTML. I filed PR https://github.com/tomaszkrajewski/tb-subswitch/pull/9 which gets you going and shows how to load and save the existing preferences in the new HTML options page. But it will need more work. I will be available for questions and support (and you are also invited to join the weekly add-on developer channel to discuss update related issues). This issue is of course also a good place to discuss the update process.

Once the HTML options dialog is done, and we can purge the old XUL dialog, we can tackle the discovery dialog.

[tomaszkrajewski]

John, how to open the popup/dialog over the new options page? I've table & basic operations there but the only idea I've found is use the pattern of opening some modal by bootstrap from https://github.com/4ch1m/mozext/blob/master/signatureswitch-me/src/options/page.js. Isn't it too complicated?

If there is a limited chance for popup, then maybe the prefix definition should be next to table, still on the main options page?

(last changes in the repository)

[jobisoft]

You should be able to use the new popover API: https://developer.mozilla.org/en-US/docs/Web/API/Popover_API

It is available since TB125.

Example: https://mdn.github.io/dom-examples/popover-api/blur-background/

[tomaszkrajewski]

John, please take a look at the repo. IMO the options are in the shape that we can move forward with the application of the prefix in the messenger compose window, and (later) recognition of prefix int the mails (by subject, headers). Please guide :)