1846274 - Add support for "runAt" in the `messageDisplayScripts.register`

Status: RESOLVED FIXED

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

Description

[juraj.masiar]

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

Steps to reproduce:

1. using extension that has [] permissions
2. execute:

await browser.messageDisplayScripts.register({css: [{code: `* {background: green}`}], runAt: 'document_idle'});

Actual results:

Uncaught (in promise) Error: Type error for parameter messageDisplayScriptOptions (Unexpected property "runAt") for messageDisplayScripts.register.

Expected results:

Currently the CSS is injected only after the whole message is fully loaded.
This can take few ms, but also many seconds.
This is visible especially when using "Dark mode" extensions (which inverts colors of the messages).
Even with small messages with no remote content, there is visible white flash. More complex emails full of remote content (like some animated gif) can load for several seconds without the injected CSS.

Applying CSS in document_idle phase would eliminate this.
Actually, just like scripting.executeScript, I would say the CSS and JS should be by default injected in document_idle phase.

Comment 1

[Alessandro Castellani [:aleca]]

Up to John to decide if this request makes sense and how to proceed

Comment 2

[juraj.masiar]

Example of how long it can take for content scripts to get injected (from "Darko" and "ScrollAywhere) - more than 30 seconds:
https://mega.nz/file/VbwDTaRY#wLnig8oIEIWjUKdTj1az7eRTt1rdJJfOOf4EeQvmnts
The email is a newsletter from Tilaa VPS provider and I can reproduce this extreme load time on my 115 and Daily 117 versions.

Comment 3

[blog]

Also just wanted to ask the Darko developer what could be done about this, then saw this bug issue here.

It's very annoying to have this timeout happen, it would be awesome if it could be addressed - thanks for all your hard work! :-)

Comment 4

[John Bieling (:TbSync)]

This issue is being looked at.

Comment 5

[david]

The same here, please fix it!

Comment 6

[darkandan]

For the love of God. Can you fix this already? It's been 5 months, and it's ANNOYING as hell. Should be marked as priority!

Comment 7

[John Bieling (:TbSync)]

This was not marked as a bug and therefore had lower priority. I will get to it as soon as my current projects are done.

Comment 8

[darkandan]

Thank you, John. Sorry for my outburst. It's just I have high brightness display in HDR mode and everything is in dark mode including Thunderbird. Because of this bug every time I open an e-mail I'm getting flashbanged by pure white background for a 0,5 sec. I suppose it should probably be marked as a bug anyway instead of enhancement?

Comment 9

[assaf_hershko]

To agree with my predecessors, I would agree that this is borderline a bug, not merely an enhancement, as it basically means dark mode (a very popular viewing mode) is broken on Thunderbird. Thanks in advance for the team, whenever they get to fixing it.

Comment 10

[m_stefanski]

+1 for this, I have just recently switched from default Windows 11 "Outlook" client since they have started to push advertisements places as mail items in inbox...

I am convinced Thunderbird will receive quite a lot of users running away from just that - and broken dark mode is a major drawback.

Comment 11

[x12dwi77]

+1 for this issue. Thank you for your amazing work on Thunderbird.

Comment 12

[felixblix]

+1 : As mentioned above - Broken (white flash) dark mode is a real thorn in the eye for most, which is a shame for such a good program.
Thank you for your great work on both thunderbird and firefox!

Comment 13

[John Bieling (:TbSync)]

Currently the CSS is injected only after the whole message is fully loaded.
This can take few ms, but also many seconds.
This is visible especially when using "Dark mode" extensions (which inverts colors of the messages).
Even with small messages with no remote content, there is visible white flash. More complex emails
full of remote content (like some animated gif) can load for several seconds without the injected CSS.

Applying CSS in document_idle phase would eliminate this.
Actually, just like scripting.executeScript, I would say the CSS and JS should be by default injected in document_idle phase.

I assume you mean document_start, right? document_idle is the default and corresponds to the "complete" readyState.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/extensionTypes/RunAt

We cannot change the default, but I am trying to support document_start and document_end.

Comment 14

[juraj.masiar]

Hmm, good point, I think I got confused by something since document_idle is the default already (but as you know, it's too late for CSS).

Maybe this is what got me confused, in Chromium the CSS is loaded before dom:
https://developer.chrome.com/docs/extensions/reference/api/scripting#property-RegisteredContentScript-css

The list of CSS files to be injected into matching pages. These are injected in the order they appear in this array, before any DOM is constructed or displayed for the page.

MDN says it's only in Chrome:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/RegisteredContentScript#runat

I think changing the default behavior for CSS would still be OK. I can't think of a use case where I would want to inject CSS only after the page is fully loaded.

Comment 15

[John Bieling (:TbSync)]

You will break all add-ons, who depend on the DOM being fully loaded. And MDN states that the default is document_idle for Mozilla, so it is out of question to change the default.

But I am trying to add the two other injection points.

Comment 16

[juraj.masiar]

I meant only for CSS files like Chromium does, or can they depend on DOM too?
That way you wouldn't have to introduce the "runAt" option :).
But I'm OK with both approaches.

Comment 17

[John Bieling (:TbSync)]

Could you attach a version of your add-on to this bug, which uses

await browser.messageDisplayScripts.register({css: [{...}], runAt: 'document_start'})

so it can be used during review, allowing reviewers to see the difference?

Once this try has finished, you can download the executable from one of the "Ba" tabs and try it out yourself. If you tell me which OS you need, I can post the link here directly.

Comment 18

[John Bieling (:TbSync)]

Attachment: Bug 1846274 - Add support for "runAt" in the `messageDisplayScripts.register`. r=#thunderbird-front-end-reviewers

This patch adds support for the 3 injection points document_start,
document_end and document_idle for message display scripts. This
allows dark reader add-ons [1] to inject their CSS at an earlier stage,
reducing white flicker.

This patch also tries to remove a flicker, which currently happens when
switching messages.

[1] : https://addons.thunderbird.net/addon/darko_t/

Comment 19

[juraj.masiar]

Attachment: darko_3_7_thunderbird_prod.zip

Sure thing!
This is not-minified version of my Darko addon (but still Webpack processed) that calls "browser.messageDisplayScripts.register" with parameter runAt: 'document_start' and currently fails (in the "background/background_d.js@837").

In the released version I'll wrap it with try/catch and I'll also update the strict_min_version once I'll know what to set there.

Thank you John for the fix! :)

Comment 20

[John Bieling (:TbSync)]

Thanks!

Note: The current patch version in the try has a logical error and does not work with the updated add-on. While developing locally, I simply enforced document_start as default (and that works), but I never tried to pass the runAt argument from an add-on and tada: That does not work yet.

I will update the bug, once that is fixed.

Which OS are you?

Comment 21

[juraj.masiar]

Edition Windows 11 Pro
Version 23H2
OS build 22631.3296

Comment 22

[John Bieling (:TbSync)]

Here is the Windows 64-bit build for you to try out:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/E80LKf93RSyO52ZXZzZDxg/runs/0/artifacts/public/build/target.zip

Make sure to start it with the -p parameter and select a test profile, so it does not upgrade your production profile to Daily.

It works with your updated add-on.

Do you also see a white flash, when your options page opens up?

Comment 23

[juraj.masiar]

Works great!
With my old addon, the flash is there, although much less noticeable than my normal Thunderbird, this Nigthly is lightning fast.
And with the updated addon, the flash is completely gone, even with the most complex emails, they load fully dark.
Thanks again for making this happen :)

Comment 24

[juraj.masiar]

And yes, there is a white flash when opening Options page, that's actually my bad for not setting background color in the main CSS, only by Vuetify which loads slightly later. With that fixed, there is almost no white flash, maybe only for a single frame. I wouldn't worry about that :)

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3aad2098b357
Add support for "runAt" in the messageDisplayScripts.register. r=darktrojan