Closed Bug 1707573 Opened 4 years ago Closed 3 years ago

messageDisplayScripts on TB 78.10: content script fails after restart

Categories

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

Product:
Thunderbird
Component:
Add-Ons: Extensions API
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: zephyr, Unassigned)

Details

Attachments

(1 file)

messageDisplayScript.xpi
775 bytes, application/x-xpinstall
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

This is a follow up to the bug 1674932. So I am going to reproduce the same steps:

Install the following add-on and open a message

manifest.json

{
  "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"
    ]
  }
}

background.js

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

content.js

console.info("Test content script executed");

Actual results:

After this add-on has been installed on Thunderbird 78.4, we can observe that:

  • At the first startup with the add-on the strings is printed on the console each time a message is display.
  • For subsequent start of Thunderbird the strings are no longer printed.
  • When changing the layout (classic/wide/vertical) of the main window, then the add-on works (and keeps working if switching back to the initial layout).

This was tested on fresh profiles, on Linux, MacOS and Windows.

Expected results:

The strings should be printed each time a message is display

Could you update to 78.10.0 and check if this is still happening?

Edit: Oh, you copy-pasted the description in comment #0 which still mentions 78.4. That threw me off. The subject says 78.10. My bad.

I still cannot confirm this. To make sure it is not just an issue with the debugger not printing the line, I updated the add-on to make the background red, so it is more obvious to see if injection worked or not.

I attached the add-on.

I've received several reports of this issue as well. For example here:
https://github.com/fastaddons/Darko/issues/13#issuecomment-791954963
("I am having a similar issue on arch linux with Thunderbird 78.8.0. No other addons. ...... it's a recurrence of the #12 vertical view thing. works good now when I changed the view like that")

Or here in the review:
https://addons.thunderbird.net/en-US/thunderbird/addon/darko_t/reviews/1166201/

I think all reports came from Linux users.

You said you reproduced this on Windows and macOS. Is that true? Or is this bug Linux-only now?

(In reply to John Bieling (:TbSync) from comment #1)

Edit: Oh, you copy-pasted the description in comment #0 which still mentions 78.4. That threw me off. The subject says 78.10. My bad.

Sorry my bad I should have been more careful.

(In reply to John Bieling (:TbSync) from comment #4)

You said you reproduced this on Windows and macOS. Is that true? Or is this bug Linux-only now?

It is. I am able to reproduce this with your add-on on all platform I use (Ubuntu 20.04.2 LTS, macOS Big Sur 11.3 and Windows 20H2) all up to date and using the latest release of Thunderbird (78.10.0). I also tried on Ubuntu 21.04 live running in a VM and obtain the same result

With your add-on, I have the same behavior as describe in the issue with the background red only when the console print works. So I do not think this is an issue with the debug tool

On Linux removing the following file ~/.cache/thunderbird/XXXXXXXX.XXXX/startupCache/startupCache.8.little make the add-on work for the next start of Thunderbird. I did not found any equivalent file on macOS or Windows on the profile folder.

Geoff, do you have any idea how the startup cache could be involved here?

Flags: needinfo?(geoff)

It looks like this code is not doing anything effective when the bug happens. If you do the same in the console then scripts begin to work.

I guess, given that blowing away the start-up cache makes a difference, that there's a timing issue here. The code I linked to must be running before something else that needs to happen.

I managed to track this down eventually in my Windows VM but I haven't got a development environment there to go any further.

Flags: needinfo?(geoff)

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

It looks like this code is not doing anything effective when the bug happens. If you do the same in the console then scripts begin to work.

I guess, given that blowing away the start-up cache makes a difference, that there's a timing issue here. The code I linked to must be running before something else that needs to happen.

The linked code is called via OnLoadMessenger which is called when messenger.xhtml loads (onload).

I think the handler for the notification is only added when an extension is started.

So my suspicion is that with the start-up cache, messenger.xhtml is loading before extensions have fully loaded.

You can probably confirm this by taking a startup profile, and looking in the marker chart for when the window starts to load, and when the extension startup is complete. It should be pretty obvious iirc, though you might need a marker for OnLoadMessenger.

If that is the case, then that may also imply that if an extension is installed whilst Thunderbird is running, then it wouldn't be able to apply the content script until after Thunderbird was restarted.

So the question would then become how should these browsers be registered on extension start, or indeed, are we registering these in the correct manner? From what I can tell there's no explicit extension-browser-inserted for browser tabs in Firefox, so how are they accessible for content scripts?

I just found a workaround for Linux:

  1. Open any file manager and look for /home/yourusername/.cache/thunderbird/xxxxxx.default-release/ (replacing "yourusername" with your system user name and "xxxxxx.default-release" with the actual Thunderbird profile folder);
  2. Set the "startupCache" folder as read-only - you can do it either with "chmod a-w startupCache" or setting it as read-only through GUI, you choose it.

That's it, DarkReader works again.

Solution for Windows:

  1. Open in Explorer: C:\Users\YourProfileName\AppData\Local\Thunderbird\Profiles\ProfileName.default\startupCache
  2. You must delete file startupCache.4.little
  3. Create a new blank 0kb file with the same name (startupCache.4.little ) and make it read-only

DarkReader works again :)

Oh man, how do you even come up with such a out of box ideas :D.

So if I understand this right, the broken "startup cache" routine executes to do its job and suddenly the storage is read-only! Then throwing some IO exception and exiting which fixes the problem. So this is the case of "Task failed successfully" :D, LOL!

Is there any way I could reproduce this? How do I get INTO this broken state? We need to fix Thunderbird to be able to detect this state and fix it automatically.

How can i help you? I'm not a programmer ;) my solution works for me

@john Try to install both extensions:
https://addons.thunderbird.net/en-US/thunderbird/addon/darko_t/
https://addons.thunderbird.net/en-US/thunderbird/addon/darkreader/
Then restart few times.
On my PC (Win 10, TB 90.0b3 (64-bit)), only Darko works. The Dark Reader was working for a while but then it broke and even after uninstalling restarting and installing back it's still broken (even the popup window is broken with some "loading" message).

OK, darkreader did something with my TB78 profile. Investigating. I wish it would do the same with my TB91 profile, but it does not seem to work at all there.

I was affected by this bug in Thunderbird 78.14.0: Dark Reader 4.9.39 stopped working after the first restart. (Ubuntu 20.04)
But with Thunderbird 91.4.0 + Dark Reader 4.9.39 it works normally on my previously affected profile. Same behaviour with messageDisplayScript.xpi.

Maybe this bug was already fixed in TB91?

Closing this as it appears to be working and there was no comment here stating otherwise for the last 4 month.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: