Convert to pure WebExtensions #1
Conversation
|
The onCommand event now has a second parameter to give you the active tab, so I could remove |
| } | ||
| }, | ||
| "name": "Copy Patch", | ||
| "description": "Copy email content to clipboard for application as patch", | ||
| "author": "Jan Kiszka", | ||
| "version": "2.1.3", | ||
| "version": "2.1.4", |
| parse5322.parseAddressList = parseAddressListSimple; | ||
| parse5322.parseFrom = parseFromSimple; | ||
| parse5322.parseSender = parseSenderSimple; | ||
| parse5322.parseReplyTo = parseReplyToSimple; |
There was a problem hiding this comment.
This looks like a valuable tool, but I'm not a fan of forking it here. We should probably make this addon an npm package so that its dependency can be pulled with standard tools.
There was a problem hiding this comment.
If you have the bandwidth to do that, this is of course doable. I did not want to force you to having to build your add-on using a complex toolchain.
|
Thanks for the conversion. The changes look helpful, will test them in a minute. However, I would rather like to do the conversion in smaller, logically separated commits. If you have the time, please factor out e.g. style changes, getCurrentWindow removal etc. Let me know if you have time to do that as well or if I should help out. |
|
What style changes are you referring to? All I did was to move your legacy code into your background and include a 3rd party library. I do not see how that can be done in smaller steps and having a working add-on after each step. What part are you worried about in particular? I could add more explanatory comments, if that would help, but I do not have the bandwidth to redo this PR. I have many other add-ons, where I have to support developers to move from legacy to WebExt: https://thundernest.github.io/add-on-reports/lost-tb102-to-tb115-worst-case.html Thunderbird will move to stable monthly releases in 2024, and it is not plausible to expect add-on devs to release a new version for their Experiment add-ons every 4 weeks. So we have to get them away from Experiments where possible. |
background-script.js
Outdated
| setTimeout(() => { | ||
| messenger.messageDisplayAction.setBadgeText( | ||
| {tabId: sender.tab.id, text: null}); | ||
| { tabId: sender.tab.id, text: null }); |
There was a problem hiding this comment.
These three are examples for style changes I was referring to.
There was a problem hiding this comment.
I will try to undo the automatic pretty format changes caused by Visual Studio Code tomorrow.
|
No problem, then I will rework the changes myself. BTW, there is also https://addons.thunderbird.net/de/thunderbird/addon/toggle-line-wrap which is still using Experiments because TB lacks that feature natively (https://bugzilla.mozilla.org/show_bug.cgi?id=1587153). Just had to bump its version as well, and if I have to do that every other month soon, that would become rather unhandy. |
|
Don't worry, I will rebuild the series to form a clean patch queue that can go into master. |
|
I think toggle line wrap can be recreated as a pure WebExtension without using any internal Thunderbird stuff. Either by using a compose script to inject a css to toggle a line wrap visually and use onBeforeSend event to actually manipulate the outgoing plaintext mail to break at the desired places, or manipulate the DOM of the message while the user is typing. |
Honestly, I would rather prefer this finally being addressed in TB because none of those solutions seems simple to me. So, if I have to invest time, that should go into a upstream patch. Let's follow up on that issue. |
| @@ -3,23 +3,20 @@ | |||
| "applications": { | |||
| "gecko": { | |||
| "id": "[email protected]", | |||
| "strict_min_version": "78.4.0", | |||
| "strict_max_version": "102.*" | |||
| "strict_min_version": "102.0" | |||
There was a problem hiding this comment.
Must become 106.0 due to using the tab parameter of the onCommand callback.
There was a problem hiding this comment.
It was backported to 102:
https://searchfox.org/comm-esr102/source/mail/components/extensions/parent/ext-commands.js#46-49
You sure it does not work?
There was a problem hiding this comment.
It is documented in the 102 branch of the API as well:
https://webextension-api.thunderbird.net/en/102/commands.html#events
There was a problem hiding this comment.
I was reading https://webextension-api.thunderbird.net/en/latest/commands.html - seems your documentation is outdated then. To which version of 102 was this added then exactly?
There was a problem hiding this comment.
But to be precise, it must be set to 102.4.0. So indeed a good catch! (102.3.3 does not exist in the list of allowed versions)
| // Many thanks to Dominic Sayers and his documentation on the is_email function, | ||
| // http://code.google.com/p/isemail/ , which helped greatly in writing this parser. | ||
|
|
||
| export function parse5322(opts) { |
There was a problem hiding this comment.
Meanwhile I understood that this was a local modification on top of the original version. But we can do better, we can go upstream first (provided upstream is still merging): jackbearheart/email-addresses#68
| } | ||
| return null; | ||
| } | ||
| // Compatibility layer for former experiment. |
There was a problem hiding this comment.
Reads like as if there could be a better way. However, to my understanding, there is no way for the content script to access browser.messages directly. Therefore, we need such an interface, no?
|
#2 is supposed to carry everything of this PR, just broken up and slightly massaged. |
This PR removes your Experiment and replaces it by WebExtension code.
To get the body, I use
messages.getFull()and search for the firsttext/plainbody part. I included a 3rd party library to parse email addresses. To make things simple, I converted the background to a module to be able to use ES6 modules.