v2 not showing the colored diffs on Thunderbird 78.4

[carlosfrodriguez]

Hi @Qeole

I updated today the add-on and restarted my TB, navigated to my git mail folder but the colored diffs are not shown.

Is there anything I need to change to activate the add on? or to debug why I can't make it work?

((enjoy))
cr

[EDIT from maintainer] TL;DR: This seems to be a bug in Thunderbird ESR 78, fixed on the development branch (not sure when). We opened a ticket on Thunderbird's Bugzilla regarding the bug. This affects Thunderbird 78.4 and 78.5, but should be fixed in 78.6.

[carlosfrodriguez]

This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. colored-diffs
Some cookies are misusing the recommended “sameSite“ attribute 10
Cookie “__utma” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmb” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmc” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmz” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmv” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utma” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmb” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmc” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmz” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite ga.js:28:213
Cookie “__utmv” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

[Qeole]

Hi and thanks for the report!

There's also a discussion in the comments for that PR, it looks like the upgrade isn't going as smooth as I had hoped.

I don't think the logs above relate to the issue, not sure how you got them but you probably want to clean the console before e.g. trying to have a patch coloured, to suppress the noise.

One thing to try is to remove the add-on, restart Thunderbird and then re-install the add-on, someone reported that it helped in their case.

Other than that, I'm still trying to pin down the cause for that bug & the conditions in which it occurs. By the way, do you manage to have the add-on working in some cases? For example if you message is displayed in the main window and tab? In a new tab? In a new window?

[Qeole]

Could you please also confirm your TB version? Is it 78.4?

[carlosfrodriguez]

Hi @Qeole

78.4.0 (64-bit) running on MacOS

I removed the add-on, restart TB, install again, restart again, same result.

To try to use it, from the main tab I just chose the folder and the mail

[carlosfrodriguez]

@Qeole ahhh it works if I explicitly open the mail in a new window.

[Qeole]

Ok thank you! No idea why it behaves like that though, but I'll keep investigating.

[Qeole]

I may have a workaround. It seems that changing the layout for the main window somehow fixes the add-on. To try this: View->Layout-><pick one different from current>. You can even restore your initial layout after that. It apparently restored the add-on behaviour on my test setup, I don't know if it's a generic workaround though, happy to get feedback.

Now, you're probably wondering why changing the layout may help? So do I! 🤷 I'll keep searching.

[carlosfrodriguez]

Hi @Qeole

Yes in deed the workaround works perfectly, but until you restart TB, then you need to apply the workaround again, seams as TB does not loading the add-on (or not initializing something correctly) by default, but until the layout is changed.

Interesting...

[Qeole]

Thanks for confirming! I also have to re-apply the workaround on restarting Thunderbird :(. Not much time to spend on this tonight, but still I checked the versions and v82 (or v84 for that matter) don't have this issue at all, the add-on work from the start. I'm starting to suspect something might have been fixed on TB at some point, maybe indirectly related to the API used by the add-on, but wasn't backported to ESR? I'll try to see if I can pin it down.

At least, the good news is that this will be fixed, eventually :/.

[carlosfrodriguez]

Yes, thank you, (crossing fingers)

((enjoy))
cr

[fbezdeka]

I have a similar problem with TB 74.4...
I can confirm that it works when opening mails in a new window, but it does not in the "preview panel".

But: Right click on your mail account (left panel) -> Open in new Window -> Plug-In starts to work even in the preview panel.
I guess it is a TB bug. The messageDisplayScripts API is quite new and was backported from the upcoming 82 release.

I reproduced it with a minimal example Add-On and the registered scripts are not executed (in the preview panel) when opening different mails.

Could someone confirm that the "open account in new window" works as another workaround?
And if so we should go to the TB bugtracker and open a bug for that.

[Qeole]

@fbezdeka Assuming you meant TB 78.4 and not 74.4. Thanks a lot for your experiments!

Opening the mails in a new window, even by clicking from the left panel, makes the add-on work for me in the new window, but not in the original one. Not sure what differs.

I'm also suspecting a bug in Thunderbird 78.4. Is your minimal reproducer available somewhere? I didn't have time to create one, would be interested to see how it behaves and if indeed the feature is broken at start-up in the main panel, I also consider opening a ticket on Bugzilla.

[fbezdeka]

@fbezdeka Assuming you meant TB 78.4 and not 74.4. Thanks a lot for your experiments!
Yes. Sorry...

I'm also suspecting a bug in Thunderbird 78.4. Is your minimal reproducer available somewhere? I didn't have time to create one, would be interested to see how it behaves and if indeed the feature is broken at start-up in the main panel, I also consider opening a ticket on Bugzilla.

// background.js
browser.messageDisplayScripts.register({
    js: [{
        file: "test.js",
    }]
});

// test.js
console.error("Test script executed");

You will notice that test.js is not executed / loaded.

[Qeole]

Minimal manifest.json, for completeness

{
  "manifest_version": 2,
  "applications": {
    "gecko": {
      "id": "test@thunder.bird",
      "strict_min_version": "78.4.0"
    }
  },
  "name": "test",
  "version": "1.0.0",
  "permissions": [
    "messagesModify"
  ],
  "background": {
    "scripts": [
      "background.js"
    ]
  }
}

Thanks for the reproducer. I tested it and it confirms all we've found so far:

• On TB 82, the content script is successfully injected from the start, and the string is logged to the console for all messages in all windows and with no further action needed.
• On TB 78.4, the string is not logged when displaying messages in the main window after the add-on is installed.
• When opening messages in a new window in 78.4, by right-clicking either on the email account (left panel) or on a message in the list, then the add-on works in the new window (Our observations seem to differ for the initial window: I still don't see the add-on working there after opening a new window. Instead, the add-on switches from silent to uncaught exception: Object).
• When changing the layout of the main window, then the add-on works (and keeps working if switching back to the first layout). This manipulation needs to be done each time Thunderbird is restarted.

With this information, I filed a bug on Mozilla's tracker. (@fbezdeka, I hope you don't mind if I reused your reproducer, given it's really small I supposed there would be no issue but maybe I should have asked first?)