1641577 - Web extension option pages do not fully load

Status: RESOLVED FIXED

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

Description

[Teal Dulcet [:tdulcet] (TB Council)]

Option pages do not fully load in Thunderbird 77. No issues in Thunderbird 68 or in Firefox. I get these errors in the console:

NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIStyleSheetService.preloadSheet] ExtensionCommon.jsm:2587
TypeError: prin.URI is null
ConduitsParent.jsm:123:58
Error: Unknown sender or wrong actor for recvCreateProxyContext ConduitsParent.jsm:321:13
TypeError: prin.URI is null
ConduitsParent.jsm:123:58
Error: Unknown sender or wrong actor for recvAPICall ConduitsParent.jsm:321:13
Error: Unknown sender or wrong actor for recvAPICall 2 ConduitsParent.jsm:321:13
Error: Unknown sender or wrong actor for recvAddListener 2 ConduitsParent.jsm:321:13
Error: Unknown sender or wrong actor for recvAPICall 22 ConduitsParent.jsm:321:13

Comment 1

[Mark Banner (:standard8)]

This works fine for me using Thunderbird 77.0b3 on Mac with Thunderbird Conversation's latest master.

I think you'll need to provide some code or example code as to exactly what isn't working.

Comment 2

[Teal Dulcet [:tdulcet] (TB Council)]

Attachment: Thunderbird console errors.png

I am working updating a Firefox emoji picker/autocorrect web extension to support Thunderbird. The HTML/CSS of the options page loads in Thunderbird 77 Beta, but none of the default options are not selected and selecting things has no effect. The options page works fine in Thunderbird 68 and every version of Firefox that the web extension supports, 63 through the latest 78 Nightly. I attached a screenshot of the errors I get in the console. If I try clicking on any of those files with the errors, I get this:

TypeError: window.top.openWebLinkIn is not a function viewSourceUtils.js:85:16

Comment 3

[Teal Dulcet [:tdulcet] (TB Council)]

Attachment: awesome-emoji-picker-thunderbird.zip

I attached a copy of the code.

Comment 4

[rugk]

Note it's interesting to see the JS does execute (you can see the Localizer writing console messages), so there has to be something else that breaks…

Comment 5

[alta88]

These errors definitely happen when loading an Options page. In my case, using an experiment would cause it to not run, but a subsequent workaround without the experiment didn't eliminate the errors, though it's unclear what effect they have. See also Bug 1607859.

Comment 6

[Mark Banner (:standard8)]

(In reply to alta88 from comment #5)

These errors definitely happen when loading an Options page.

They do not happen for Conversations, which uses a html page that opens in a tab.

I just tried setting Conversations to not open a separate tab, and the only errors I got were:

TypeError: prin.URI is null ConduitsParent.jsm:123:58
Error: Unknown sender or wrong actor for recvCreateProxyContext ConduitsParent.jsm:321:13

However the page was working fine, and I could set preferences (it is basically standalone, using html/javascript/react and then browser.storage.* direct).

In my case, using an experiment would cause it to not run, but a subsequent workaround without the experiment didn't eliminate the errors, though it's unclear what effect they have. See also Bug 1607859.

Unfortunately, there's no simple demonstration of the issue here, I had a brief look a tdulcet's add-on but the code is too complex to identify what is doing what, and hence it isn't possible to quickly narrow down the issue. My suspicion would be you're trying to use message ports to pass messages back and forth, but I have no idea if that's actually the case.

I'd recommend either getting a reduced test case and/or running mozregression with the add-on to see if a regression range can be narrowed down, maybe to a specific bug.

Comment 7

[Teal Dulcet [:tdulcet] (TB Council)]

I ran mozregression twice and got this:

Bug 1602584 - Follow-up: Use force_skip for disabling on all platforms. r=me
https://hg.mozilla.org/comm-central/rev/d8d88f20aa207a30b777ec63b191d15579c8561c

Although, that is just modifying a test, so I am not sure what this means.

Comment 8

[Teal Dulcet [:tdulcet] (TB Council)]

I believe the regression is from mozilla-central. There were 83 pushes to mozilla-central between the above commit to comm-central (21 Dec 2019 12:52:52) and its parent (20 Dec 2019 23:50:38): https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1759c1b2fa6b663a475d23450148ac4a351704dc&tochange=de230ce6bd5058c0608cddfb4b6c1fb3afb62759. Only three of those were related to extensions and only one actually modifies the extension code: Bug 1604058 (https://hg.mozilla.org/mozilla-central/rev/ed6c8bbe42f790205ab9de0fcb41ae542873d135). This is also the same bug that @alta88 marked as regressing Bug 1607859.

Comment 9

[alta88]

This problem has gotten worse on current trunk, 79. In an options page, certain WE api calls now fail. All that needs to be done to test is to go to the content/options.html window context in developer toolbox; in the new context a simple console command:

browser.runtime.sendMessage({ "test":"test sendMessage" });

will result in Error: Unknown sender or wrong actor for recvRuntimeMessage. The same thing works in 78beta. It doesn't seem Firefox uses the same paradigm, as there is no equivalent window context in their current inline addons manager Options pages in browser toolbox.

So now it's not possible to send pref changes to background.js using sendMessage, for example.

Comment 10

[Mark Banner (:standard8)]

(In reply to alta88 from comment #9)

So now it's not possible to send pref changes to background.js using sendMessage, for example.

It may not be viable for you, but a possible work around would be to listen for events on the storage. For conversations, when the options UI changes, we set the value directly in the storage. We then have a listener in the background scripts for changes to the storage.

Obviously, this should be fixed, but that might get you going in the meantime.

Comment 11

[alta88]

Yes, thanks, I'm aware of that method, and it would be a (roundabout) workaround for the next esr. It's just one example though, something like:

browser.windows.create({ url: "content/options.html", type: "popup" })

also fails. From what I looked at in the other bug I filed, it seems to be an internal accounting of requests malfunction.

Comment 12

[Geoff Lankow (:darktrojan)]

Perhaps :zombie can shed some light on this. What I have managed to figure out is that when we get to receiveMessage the sender argument has a different numeric suffix compared to what's in Hub, for example the argument would be "foo@bar.39" but Hub would have an entry for "foo@bar.35".

Comment 13

[Geoff Lankow (:darktrojan)]

The message about a missing stylesheet is a real error but I don't think it's causing the problems here.

Comment 14

[Tomislav Jovanovic :zombie]

(In reply to tdulcet from comment #0)

TypeError: prin.URI is null
ConduitsParent.jsm:123:58

This is the important error. It seems that windowGlobal[Parent].documentPrincipal is invalid in some way:

1. not recognized as an addon principal, and
2. doesn't have a valid .URI.

https://searchfox.org/mozilla-central/rev/2c1092dc68/toolkit/components/extensions/ConduitsParent.jsm#120-124

I have no idea why or how that would happen (I can't debug thunderbird right now), but that is a critical security function that verifies we can trust messages coming from that extension context, so not sure if there's an easy workaround here without understanding what's really going on.

Comment 15

[Geoff Lankow (:darktrojan)]

I think this is an e10s problem. In Thunderbird the option page's parent is the Add-On Manager, which is in the same process. In Firefox the page's parent is null, because it's not in the same process. In that case verifyEnv returns true, instead of looping and failing because prin.addonId is "".

Comment 16

[[e-mail]]

I don't know whether it helps anyone else out, but I've found that I can work around the problem by adding the following line of code to my options script:

window.browser = window.browser.extension.getBackgroundPage().browser;

Comment 17

[Teal Dulcet [:tdulcet] (TB Council)]

With the workaround from comment 16, the options page will fully load, but changing the options has no effect (see here). I am using the AutomaticSettings library. This is currently blocking me from releasing two extensions for Thunderbird.

Comment 18

[John Bieling]

Could you programmatically change a setting using storage.local in your options page? Just to check if the API calls works or not? The AutomaticSettings library seems to use storage.sync, which might cause other issues.

Comment 19

[Teal Dulcet [:tdulcet] (TB Council)]

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

Could you programmatically change a setting using storage.local in your options page? Just to check if the API calls works or not?

I just tried using storage.local with both Thunderbird 78.5 and 84 Beta, but got the same errors.

Comment 20

[Geoff Lankow (:darktrojan)]

This should be fixed now that we are multi-process. Coming to a beta near you soon.