Implement content script - unsafe script communication

[fregante]

Implement content script - unsafe script communication

[fregante]

I think I'm going to implement the messaging primitive first, as a separate module that exports sendMessage() and onMessage() (usable in both the content script and unsafe script).

The implementation will probably be based on pixiebrix/pixiebrix-extension#1019 or what was discussed within it.

This is because, as that PR shows, there's no straight-forward way to send messages to the other side, so it would be easier to "polyfill" the sendMessage/onMessage API and then just use that as a medium, rather than attempting RPC-style calls without a solid messaging base.

[fregante]

Thinking out loud here.

---

Let's say we have a handler in a content script; How do we reach it?

• from the background: {tabId, frameId}
• from the dev tools: "contentScript" (one and only)
• from the sidebar: "contentScript" or {tabId, frameId, context: "contentScript"}
• from the unsafe context: {extensionId, context: "contentScript"}

I think getContentScriptMethod is currently flexible enough to allow this at the call site, for example:

webext-messenger/test/demo-extension/contentscript/api.test.ts

Line 21 in 82502c2

await setPageTitle(target, "New Title");

Here, the method exported by contentScript/api.ts could be called as:

// From the background
setPageTitle({tab: 1, frame: 0}, 'New title');

// From dev tools
setPageTitle({}, 'New title');

// From the sidebar
setPageTitle({}, 'New title');

// From the unsafe context
setPageTitle({extensionId: "mlhlldlpep22445"}, 'New title');

The contexts 2 and 3 don't look great, but they're ok.

For the background page, I think the extension ID can be specified while creating the method, only if it's meant to be accessible from the unsafe context. So this line:

webext-messenger/test/demo-extension/background/api.ts

Line 3 in 82502c2

export const sum = getMethod("sum");

Would just become, for example:

export const sum = getMethod("sum", "mlhlldlpep22445");

And that would be the signal that the method can also be used from the unsafe context, without having to alter the method’s signature.

[twschiller]

Would just become, for example

I think that approach looks pretty good. Let's give it a try

Other things we might consider for "unsafe"/external:

• We could consider supporting an "allowlist" of external contexts that are allowed to send messages. (The user would opt-in to communication from certain sites)
• We could consider supporting a way for an external context to send a special "request message" privileges (or something similar) that the extension can then use to prompt for the allowlist. I would imagine handlers would be inaccessible from the external context by default, but could opt-in to certain handlers accepting messages from external senders not on the allowlist

[fregante]

Just for context, some code for this now exists at https://github.com/pixiebrix/pixiebrix-extension/blob/7ee1e1292db066b074818089944020418ca18dee/src/utils/postMessage.ts#L1