Does this include css scripts?

I'm not sure if javascript will ever work on the email body itself, given that we disable the javascript at the docshell level.

I maintain an add-on that translates words as you hover over them with a mouse. Many folks are apparently still using Thunderbird 52 because they can't live without this functionality and I can't find a way to provide it through Web Extensions yet so it would be nice if we can find a way to solve this (I might even be able to find some resources to help with implementing it if we do).

Brian, I'm thinking this could work with access to the selected text as noted in bug 1590121, and a composeAction. It wouldn't be quite as comfortable as just hovering over the words, but the user could select something and then click the composeAction button.

For this bug, I agree with Mark that we'll have trouble getting content scripts to run given javascript is disabled for emails. We'd need a more declarative API that would allow making specific manipulations. I've filed bug 1590121 with a bunch of use cases not knowing about this bug. Geoff, do you want to mark this a duplicate of that bug, or would you prefer to keep this separate to find a solution that would involve content scripts?

Philipp, I'm a bit confused by the references to bug 1590121 since they are to do with the compose window. I'd want at least the css part of this for message display as well, and Brian's issue seems to be more about message display - which might be fulfilled close enough with menus.

(In reply to Philipp Kewisch [:Fallen] [:📆] from comment #4)

For this bug, I agree with mark that we'll have trouble getting content scripts to run given javascript is disabled for emails. We'd need a more declarative API that would allow making specific manipulations. I've filed bug 1590121 with a bunch of use cases not knowing about this bug. Geoff, do you want to mark this a duplicate of that bug, or would you prefer to keep this separate to find a solution that would involve content scripts?

It'd be nice to address the css part somewhere at least.

(In reply to Philipp Kewisch [:Fallen] [:📆] from comment #4)

Brian, I'm thinking this could work with access to the selected text as noted in bug 1590121, and a composeAction. It wouldn't be quite as comfortable as just hovering over the words, but the user could select something and then click the composeAction button.

Right, the add-on I maintain used to have a XUL version that allowed hovering words in either compose view or message view. The API you describe would probably be sufficient for the compose view (since it is mostly used there to check you are using the words correctly and hence the hovering is less important).

Brian's issue seems to be more about message display - which might be fulfilled close enough with menus.

I wonder if menus would allow the hovering behavior? That's the key feature of my add-on (Rikaichamp) and there are similar add-ons for other languages that rely on hovering as the primary means of interaction (e.g. Mouse dictionary).

(In reply to Mark Banner (:standard8) from comment #5)

Philipp, I'm a bit confused by the references to bug 1590121 since they are to do with the compose window.

Oh, sorry about that. I was just thinking HTML editor for some reason, so my comments are mostly moot. The part about not being able to execute JavaScript is a problem though. Random idea, maybe it is possible to have content scripts run on a frame that is guaranteed to be in the same process as the email display, and then being able to access the email display via a property on the window.

Applying CSS would definitely be good!

(In reply to Brian Birtles (:birtles) from comment #6)

Brian's issue seems to be more about message display - which might be fulfilled close enough with menus.

I wonder if menus would allow the hovering behavior? That's the key feature of my add-on (Rikaichamp) and there are similar add-ons for other languages that rely on hovering as the primary means of interaction (e.g. Mouse dictionary).

If it doesn't now, I'm thinking the menus API should allow taking action on selected text in an email, both in the message view and compose windows. The other alternative (or addition) would be something on the messageDisplay API that would give access to selected text. These are likely separate bugs, maybe you could file something new?

(In reply to Philipp Kewisch [:Fallen] [:📆] from comment #7)

(In reply to Mark Banner (:standard8) from comment #5)

Philipp, I'm a bit confused by the references to bug 1590121 since they are to do with the compose window.

Oh, sorry about that. I was just thinking HTML editor for some reason, so my comments are mostly moot. The part about not being able to execute JavaScript is a problem though. Random idea, maybe it is possible to have content scripts run on a frame that is guaranteed to be in the same process as the email display, and then being able to access the email display via a property on the window.

That would probably work, sounds similar to what Conversations does currently - it accesses the iframe via iframe.contentDocument, and injects dom elements. It looks like you can even set click handlers on the dom elements directly from there.

(In reply to Philipp Kewisch [:Fallen] [:📆] from comment #7)

If it doesn't now, I'm thinking the menus API should allow taking action on selected text in an email, both in the message view and compose windows. The other alternative (or addition) would be something on the messageDisplay API that would give access to selected text. These are likely separate bugs, maybe you could file something new?

I went to file this bug, but from what I understand from comment 8 it looks like I might not need to if we're able to access the iframe directly. For what it's worth the add-ons that I am describing are not like Mac's tap-and-look-up behavior. Rather they operate by hovering only and actually perform the selection themselves (although in future I hope the Highlight API will be able to be used for this).

The workaround mentioned in the last comment seems difficult for me to understand. Does the comment say: we can access the selected text in the mail content using iframe or newly injected DOM element? I am desperately waiting for this bug to get fixed. As one of the productivity addons i developed for my org is broken in Thunderbird versions >= 68. It would be a great help if someone pitches in and fixes this. Just to give a context, i had filed the bug: 1579059 which has been marked as a duplicate of this.

You do not need this bug fixed to make an add-on work in 68.

So, my requirement is to select a text in mail content body and pass the selected text as input to custom url which is defined as part of a context menu.

browser.menus.onClicked.addListener((info, tab) => {
switch (info.menuItemId) {
case "open_customlink":
console.log(info.selectionText);
openCL(info,tab);
break;
});

But, when i try to print the info.selectionText value is Undefined as observed in Bug 1579059. How to overcome this? How to get the selected text information from mail content?

You say you have an existing add-on. It's going to be much easier (and quicker) for you to adapt that to make it work on 68 than to wait for the APIs to be ready (and backported to version 68, which might never happen). Here's the documentation to use as a starting point or if you need help visit the add-ons discussion group.

Alternatively, you might be able to work your existing code into a WebExtensions experiment, but having not seen your code, I couldn't say whether or not that would be a good idea.

Just to record here that, i have already ported my add-on to Thunderbird 68 based on the documentation. Even the context menu is getting displayed but the selected text from the mail content is missing (Undefined) leaving my add-on useless. Thank you for reopening the duplicate bug.

Even though JavaScript is disabled in emails, why not allow it for extensions? With some new accessEmails permission it would make sense and it would allow many useful extensions to work there.

I'm author of ScrollAnywhere which needs to be able to execute JavaScript in emails in order to work there.

(In reply to juraj.masiar from comment #15)

Even though JavaScript is disabled in emails, why not allow it for extensions? With some new accessEmails permission it would make sense and it would allow many useful extensions to work there.

Unfortunately you can't allow it for one and not the other. It just isn't safe. Javascript is disabled at the docShell level - the docShell is what controls the display of the document. If you're an extension trying to inject script into that, then it won't work.

You can do things from outside the document, e.g. after the email loads or with a wrapper similar to what Phillip mentioned in comment 7.

Thunderbird extensions have been working this way forever, we just can't do it the same way as Firefox here as we can't allow that permission.

If I'm not misunderstanding this will never be fixed, but access to mail body can be done from a script outside the displayed email. Can we have an example?

(In reply to Massimo Fidanza from comment #17)

If I'm not misunderstanding this will never be fixed, but access to mail body can be done from a script outside the displayed email. Can we have an example?

Currently there's no way to do either part. You can use WebExtension experiments to access the body the same way as you did in the past.

This API would be quite interesting to get in, if we figure out the technical hurdles.

Might be worth starting with looking at getting css injection going first and do javascript second. The css injection will probably be simpler overall, and inform some of the javascript side of things.

I have a working prototype. Now to iron out the wrinkles.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/465a303b8252
Add an API for running content scripts in message display browsers. r=mkmelin

This is amazing news! Thank you for working on this Geoff!
If you have time, could you share some details on how to test it?
If I see right, I need a new "messagesModify" permission. And then my content script will be injected into emails?
I've tested it with new build "82.0a1 (2020-09-09) (64-bit)" but it doesn't look like it's running...

Or am I here way too soon and these changes will part of the next+next Thunderbird ESR next year?

It's very similar to the compose scripts API with some examples here – just use browser.messageDisplayScripts instead of browser.composeScripts. Note that ordinary content scripts (as you may be used to from Firefox, etc.) don't work in messages.

Thank you Geoff. I've just tested it with my ScrollAnywhere using:

await browser.messageDisplayScripts.register({js: [{ file: "/content_script/scroll_anywhere.js" },],})

And it works! Without changing anything (except for new manifest permissions). So this is amazing!
Thanks again! This will make many people very happy!

Hi, thanks a lot for this new API! I have also managed to use it successfully to port an add-on.

One question on its landing, please. The new API is now in v82, so if I understand the release process correctly, it should be available to the majority of users in the stable release v88, is this correct? Unless it is backported before that I suppose?

If all goes well with our beta users I intend to put it in 78.4.

Fantastic, thank you!

Great news if it included in 78.4!

Of course it would be helpful if potential users of the API joined our beta channel and found problems before it was uplifted to release.

(In reply to Geoff Lankow (:darktrojan) from comment #34)

Of course it would be helpful if potential users of the API joined our beta channel and found problems before it was uplifted to release.

I'm running Earlybird at home now to port my add-on, and at work to use said add-on. Does that count? Or do you mean something else by joining the beta channel? Happy to get pointers.

Regarding the new API, I have one observation. I am loading background script code from several JavaScript files in my manifest.json, this looks like:

  "background": {
    "scripts": [
      "global_vars.js",
      "background_script.js"
    ]
  },

Because they run in the same context, I can access objects defined in the first script global_vars.js from the second one, background_script.js. Now I can use the same mechanism when injecting content scripts from multiple files with browser.messageDisplayScripts.register(). I thought about doing like this:

        browser.messageDisplayScripts.register({
            js: [{
                file: "global_vars.js",
                file: "content_script.js",
            }],
        });

... But this won't work in that case. The scripts are all in the same context, but it seems that the objects from global_vars.js are not yet defined when content_script.js runs. Instead I have to use the following:

    browser.messageDisplayScripts.register({
        js: [{
            file: "global_vars.js",
        }],
    }).then(() => {
        browser.messageDisplayScripts.register({
            js: [{
                file: "content_script.js",
            }],
        });
    });

In that case I can access my objects defined in the first script from the second one.

I don't have any knowledge of the internals for loading scripts, or on how JavaScript pieces share their context in general, so this may very well be an expected behaviour. But I thought I would just ask?

(In reply to Qeole from comment #35)
Surely you want:

        browser.messageDisplayScripts.register({
            js: [{
                file: "global_vars.js",
            }, {
                file: "content_script.js",
            }],
        });

You can't specify file twice in the same object, that's not going to work. (I'm not currently in a position to check this, but it seemed like the obvious problem.)

Ah right of course, I was trying to add twice the same property to an object -_-. That was a silly question, sorry for the noise. With your suggestion it works just fine, thanks a lot!

Just wanted to tell you, I've been testing this for a week now (in Win10 and Ubuntu 20.04) and it works perfectly. Both JS and CSS injection using:

await browser.messageDisplayScripts?.register({js: [{file: '/content_script/scroll_anywhere.js'}]});
await browser.messageDisplayScripts?.register({css: [{code: css}]});

If someones interested in fancy scrolling and customizable scrollbars, there is now ScrollAnywhere for Thunderbird :).

Thanks again @Geoff for making this happen and good luck with the uplift!

Comment on attachment 9173940 [details]
Bug 1504475 - Add an API for running content scripts in message display browsers.

[Approval Request Comment]
New WebExtensions API
Testing completed (on c-c, etc.): on beta since 82.0b1
Risk to taking this patch (and alternatives if risky): none

ESR version of the patch.

[Approval Request Comment]
New WebExtensions API
Testing completed (on c-c, etc.): on beta since 82.0b1
Risk to taking this patch (and alternatives if risky): I did have to make some changes to how this works, which are obviously untested on beta, but I'm reasonably confident they won't cause problems.

Comment on attachment 9179824 [details] [diff] [review]
1504475-esr.diff

[Triage Comment]
Approved for esr78

Thunderbird 78.4.0:
https://hg.mozilla.org/releases/comm-esr78/rev/56b3590f01ff