1722065 - The `browser.messageDisplayScripts` API is no longer applied applied in currently opened message

Status: RESOLVED WORKSFORME

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

Description

[juraj.masiar]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

This is a regression in:
91.0b3 (64-bit)
Working version:
91.0b2 (64-bit)

STR:

1. install Darko:
   https://addons.thunderbird.net/en-US/thunderbird/addon/darko_t/
2. open message
3. click Darko icon in the toolbar to toggle dark mode in the message

Actual results:

Nothing, dark mode is not activated.
It will be activated after closing / reopening the message

Expected results:

Registering/unregistering a messageDisplayScript should inject it in current message.
Example:

 const {unregister} = await browser.messageDisplayScripts.register({css: [{code: 'background: darkred'}],});

Comment 1

[juraj.masiar]

Attachment: bug demonstration

Hello again,
Could someone look into this before we reach Thunderbird 91? There is not much time left.
The bug can be reproduced by calling this line (in a console of addon that has messageDisplayScripts permission):

const {unregister} = await browser.messageDisplayScripts.register({css: [{code: '* {background: darkred}'}],});

and then:

unregister();

Which will NOT unregister the script in the currently displayed message.
The regression window is 91.0b2 - 91.0b3.

Comment 2

[John Bieling (:TbSync)]

@darktrojan: In https://bugzilla.mozilla.org/show_bug.cgi?id=1715434#c3 you stated basically what this bug report is about. Do you have an idea where we should look to fix this?

Comment 3

[Geoff Lankow (:darktrojan)]

This is the behaviour you'd get in Firefox if you did the same thing with the content script API. If you want to hit already-open messages, you'll need to call executeScript/insertCSS.

Comment 4

[juraj.masiar]

I see... makes sense to stay compatible with Firefox API.

But will removeCSS work for the CSS inserted using messageDisplayScripts.register method?
I think I'm still screwed because I won't be able to toggle OFF dark mode in the currently displayed message. Or maybe I simply reload it (if there is API for that).

Comment 5

[John Bieling (:TbSync)]

But will removeCSS work for the CSS inserted using messageDisplayScripts.register method?

Can you give it a try? Would be interesting to know.

Comment 6

[juraj.masiar]

Nice! It works :)
I can remove my dynamic CSS code with browser.tabs.removeCSS({code: CSS_CODE});.
I'm surprised how easy I was able to fix it. Simply calling browser.tabs.insertCSS after registering and then removeCSS after unregisterring. Piece of cake :)
Thanks!

Comment 7

[John Bieling (:TbSync)]

To understand this and being able to guide others: You are doing both now? You are registering your CSS and also call insertCSS? Or did you change the code to always use insertCSS?

If you do both, are you sure both calls do not interfere?

Comment 8

[juraj.masiar]

I'm doing both.
There shouldn't be any interference if you use it in the new Thunderbird 93 because registering won't apply it anymore to the current message. And when you open new message, only the registered is inserted.
But I have some bug in there because it's a bit buggy now :), but I don't think it's related.

This is my code:

const {unregister} = await browser.messageDisplayScripts.register({
  css: [{code: CSS_CODE}],
});
// in the new Thunderbird 91 we need to insert and remove CSS from the current tab manually. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1722065
await browser.tabs.insertCSS({code: CSS_CODE});
unregisterFn = () => {
  unregister();
  browser.tabs.removeCSS({code: CSS_CODE});
};

However in the 78 it will inject it twice and remove it twice. This is most probably not a problem with CSS, but with JavaScript it would for sure require some check (like defining some global property on window... but probably there is a better way to check if script is already inserted, without sending it a ping message, which would work as well).

Comment 9

[John Bieling (:TbSync)]

How about not using browser.messageDisplayScripts.register, but browser.messageDisplay.onMessageDisplayed and "manually" call injectCSS there? And for the enable/install part, do it like you do it now? This way you are no longer doing both, which I think we should avoid.

Comment 10

[juraj.masiar]

Sounds reasonable, but still, I don't see a problem in 91 with the current approach, it's short and clear.
Also I think you need a messageRead permission to access browser.messageDisplay, so that may be an issue for some addons.