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! :shrug: 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": "[email protected]",
      "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?)

[fbezdeka]

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?)

That's absolutely fine. That's why I posted it... Thanks for creating the TB issue.

[Qeole]

I understand that the relevant patch is being backported to Thunderbird ESR, and the issue should be fixed for v78.6. :tada:

[fbezdeka]

I installed [1] on my system and the plugin now works as expected. So yes, upstream bug fixed :tada:

It may take some time until the fix is distributed, but hopefully distros will update soon, there are some CVEs fixed as well.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-a7b6d9467e

[Qeole]

Great, thanks a lot for checking and confirming! I'm running with the version from thunderbird.net with automatic updates and I just got upgraded to 78.6, where the plugin works well indeed. Looks all good, I'll close this issue.

[marxin]

I can confirm that with 78.6 that is approaching openSUSE Tumbleweed. Thank you very much!

[zickgraf]

I am still seeing this issue with Thunderbird 78.6 (Arch Linux, happens with both the Arch version and the Mozilla binaries). In fact, the plugin works when launching Thunderbird for the first time after an update (or downgrade), but not on subsequent starts (except when changing the layout). Can anyone reproduce this?

[Qeole]

@zickgraf I'm not able to reproduce on Ubuntu with v78.6.0 from thunderbird.net's binaries :confused:. Any chance you could try with the current beta or nightly version? (Use a copy of your profile, because downgrades are not recommended so you might have issues when going back to v78 otherwise.)

[zickgraf]

@Qeole Thanks for checking! That's weird, I can reproduce this even in a clean virtual machine. I will list detailed steps to reproduce, maybe you can spot a mistake:

1. Start a live session from a Ubuntu 18.04 image
2. Download Thunderbird 78.6 from thunderbird.net (https://download.mozilla.org/?product=thunderbird-78.6.0-SSL&os=linux64&lang=en-US)
3. Extract and launch Thunderbird
4. Enter account details
5. Install Colored Diffs version 2.1.0 (https://addons.thunderbird.net/en-US/thunderbird/addon/colored-diffs/)
6. Select an email sent via "git send-email" so it's displayed in the message pane: diff is colored
7. Close and reopen Thunderbird
8. Select the same email as in step 6: diff is not colored
9. Switch from the default "Classic View" to "Wide View" or "Vertical View": diff is colored again

If I use Thunderbird Beta 85.0 instead, the issue does not occur.

Can you spot an obvious mistake? If not, I assume this has to be something specific to the mail account I'm using, then I would just switch to beta for now.

[Qeole]

Ok you're right, I do reproduce with a clean profile :confused:. There is some improvement with 78.6, because previously I would experience the issue on other profiles too, but this has been fixed somehow. I have no idea at the moment of where the difference is :confused:.

I'll try to investigate a bit further but at this point I'm not sure what I can do. I can always re-open the bugzilla ticket, but I'd like to have a bit more info so they can pin down the issue. If you can run the beta I suppose that's a workaround, I don't have anything better to suggest unless we figure out what makes it work on some profiles.

[zickgraf]

Thanks for investigating further! I was starting to get worried about why I should be the only one seeing this issue :D

I have just tried simulating a "used profile" by creating a new profile with version 78.5, installing the plugin, and then updating to 78.6, but this does not "fix" the issue. Since I don't have a working profile I'm out of ideas of things I could try.

One other observation, which might help to narrow down the issue: As mentioned above, the issue does not occur on the first launch after an upgrade or downgrade (for example when switching back and forth between 78.5 and 78.6). This seems to be due to the fact that in this case the startup cache is ignored: If I manually delete the startup cache (~/.cache/thunderbird/XXXXXX.XXXXXX/startupCache/startupCache.8.little), the issue does not occur on the next launch. This seems to point to some kind of race condition. And with this "trick" it even works in version 78.5, so maybe we are even observing a different issue than the one fixed in 78.6.