Closed Bug 1622502 Opened 4 years ago Closed 4 years ago

Unable to load content script from Thunderbird mailextension

Categories

(Thunderbird :: Add-Ons: Extensions API, defect)

Product:
Thunderbird
Component:
Add-Ons: Extensions API
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: tonp, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362

Steps to reproduce:

TB74 does not support xul mailextensions anymore. In process of porting our existing AddOn we're trying to load script into the (main) mail tab, the goal is to modify certain UI elements (which is not covered by the mailextension API). None of the three suggested methods at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts seem to have any effect. The executeScript method is observed to load our javascript file from disk but no script code is executed. A similar report on this can be found here: https://stackoverflow.com/questions/59547118/how-to-write-a-thunderbird-extension-webextension-to-modify-the-message-displa
Documentation on TB URL matches could be helpful too.

Actual results:

The javascript code should be injected in the TB mail tab, a console.log('Hello') message does not appear in the browser console. This behavior works fine for our background scripts.

Expected results:

Content script should be loaded be either the mainfest.json method, the contentScript method or the executeScript method. The console.log message should appear.

Content scripts in email are already covered in bug 1504475.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

This is not abount handling (or seeing) the content of an email. The linked bug report deals with email content specifically. It says: "Javascript is disabled at the docShell level - the docShell is what controls the display of the document. " Is the referred 'document' the email or the html web page? The task that we need to accomplished is changing (disabling/enabling) some UI elements (mail header buttons) through the DOM. If this is not possible and never will be possible we have to investigate other solutions outside of TB (since webextension experiments have a finite lifespan too), loosing several years of development. It would seems that mailextensions have a much more limited functionality than webextensions in this case. From https://extensionworkshop.com/documentation/develop/comparison-with-xul-xpcom-extensions/ I quote:

  • Compared with XUL/XPCOM extensions, WebExtensions provide much more limited options for the extension’s UI, and a much more limited set of privileged JavaScript APIs.
  • WebExtensions can only access web content by injecting separate scripts into web pages and communicating with them using a messaging API (note, though, that this is also true of XUL/XPCOM extensions that expect to work with multiprocess Firefox).

The WebExtensions option at least allows a way forward but from the docShell remark I guess MailExtensions do not support this route.

(In reply to tonp from comment #2)

This is not abount handling (or seeing) the content of an email.

Sorry, your first comment was unclear.

The linked bug report deals with email content specifically. It says: "Javascript is disabled at the docShell level - the docShell is what controls the display of the document. " Is the referred 'document' the email or the html web page?

In that case we were talking about the docshell belonging to the document that displays the email.

The task that we need to accomplished is changing (disabling/enabling) some UI elements (mail header buttons) through the DOM.

At the moment you can use WebExtension experiments to have access to the DOM. However, they are unlikely to be around forever and working towards a more permanent solution is strongly advised.

If this is not possible and never will be possible we have to investigate other solutions outside of TB (since webextension experiments have a finite lifespan too), loosing several years of development. It would seems that mailextensions have a much more limited functionality than webextensions in this case.

Rather than whining, please can we have a constructive discussion about what you actually want to be able to do and why? Content scripts seem like the wrong option in your case, but maybe there's something else that will help (see below).

  • Compared with XUL/XPCOM extensions, WebExtensions provide much more limited options for the extension’s UI, and a much more limited set of privileged JavaScript APIs.

Yes, this is intentional for many reasons.

  • WebExtensions can only access web content by injecting separate scripts into web pages and communicating with them using a messaging API (note, though, that this is also true of XUL/XPCOM extensions that expect to work with multiprocess Firefox).

The main UI of Thunderbird will never be accessible via a content scripts (just like in Firefox) - only web pages displayed in tabs, and maybe email message bodies once the other bug is fixed.

If you want to be able to disable specific buttons (or change other items), I think you need to build a case for what you want to do and why. For example, if your users aren't allowed to delete emails, then that could be something better supported by having an enterprise policy or some other built-in function to disable/hide the delete button. There's other possible cases as well, but I can only guess to know the functions you are providing.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---

Thanks for the response. Although I still would be interested to know if the original bug report (are we expected to see console.log output) is indeed a bug or the expected behavior, here is one of my use cases.

The displayed email message has a message header with several buttons: reply, reply all, forward, etc. I would like to change the behavior of the reply button (or hide this button and create a new one): 1. set another button text, e.g. ‘accept’ and when clicked: 2a. Change some email headers (likely in a background script) and directly send the mail without any other changes or 2b. Change some email headers and load the compose window to allow the user to make content changes.

Any idea what the best way is to accomplish this?

Thanks!

(In reply to tonp from comment #4)

Thanks for the response. Although I still would be interested to know if the original bug report (are we expected to see console.log output) is indeed a bug or the expected behavior, here is one of my use cases.

There's not much information in comment 0, but from what I can tell of what you're describing, that's the previously referenced bug 1504475.

The displayed email message has a message header with several buttons: reply, reply all, forward, etc. I would like to change the behavior of the reply button (or hide this button and create a new one): 1. set another button text, e.g. ‘accept’ and when clicked:

I don't think here's currently an API to do this, bug 1530122 is probably the closest at the moment.

2a. Change some email headers (likely in a background script) and directly send the mail without any other changes

This is bug 1545930.

or 2b. Change some email headers and load the compose window to allow the user to make content changes.

There are compose APIs to open the window, but I suspect they're not enough to allow you to do what you need to.

Any idea what the best way is to accomplish this?

At the moment, I'd suggest using WebExtension experiments as an interim to implement APIs you'd like to see. If possible you can then contribute those back to Thunderbird and get them included in core.

For this bug we could probably close it, and you could file a new one for the compose APIs, and maybe the specific bit about email toolbar changing.

I'll start working on the WebExtension Experiments version, this bug report can indeed be closed. Thanks for the the help.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → S3

The severity of these bugs was changed, mistakenly, from normal to S3.

Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.

Severity: S3 → --
Status: REOPENED → RESOLVED
Closed: 4 years ago → 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.