Implement extension page - background page communication

[fregante]

Implement extension page - background page communication

[twschiller]

extension pages should have the same permissions as the background page

Hmmm. I thought they might not have access to browser.tabs.sendMessage but it looks like they do?

so there shouldn't be any need for the extension page to call a function in the background or vice versa

IIRC, there shouldn't be any need to. However in practice we do it for simplicity (e.g., reportError gets routed through the background page)

For example the sidebar can communicate directly with the content script (of any tab).

See response above. It looks they can given that they have browser.tabs.sendMessage

Likewise, is there any reason for a content script to communicate to the options page?

No. The only possible case I could think of is if we embedded a form or some other thing that set local state. (But at that point 1) the content script would be performing the action via the background page, and 2) the background page could choose to notify the options page or the options could listen for storage change events

can you list every messaging route and direction

I think the missing ones/directions are. I'll noodle on this a bit more though:

• background -> CS: the background page has webNavigation permission it uses to notify the content script of page navigation in SPAs
• background -> devtools: I think same as for background -> CS
• CS -> unsafe script (on any website): to execute bricks that read from the web application state (e.g., window or the React application state)

but devtools.eval() should be used instead

I'd probably err on whatever has the easiest developer ergonomics for us

[fregante]

I think this is not necessary for PixieBrix, but I may be wrong.

From what I understand, extension pages should have the same permissions as the background page, so there shouldn't be any need for the extension page to call a function in the background or vice versa.

Likewise, is there any reason for a content script to communicate to the options page?

We only have 3 limited contexts:

• content script
• dev tools
• unsafe script

Every other page, including the sidebar, are just extension pages with complete permissions. For example the sidebar can communicate directly with the content script (of any tab).

Maybe the only situation I can think of is the dev tools communicating directly to the sidebar, which would require this channel.

@twschiller can you list every messaging route and direction currently in PB? And also what you're seeing in the future?

I think we have:

• CS -> background
• dev tools -> background
• dev tools -> CS (through background)
• dev tools -> unsafe script (may be via CS and background, but devtools.eval() should be used instead)
• app.pixiebrix -> background (externally_connectable, via CS only in Firefox)
• any website -> CS (future API) (externally_connectable is not available on all_urls)

Any route or direction missing? Are the sidebar and options page connecting anywhere?

It seems to me that all of them are mono-directional — that is, only ever one side starts the communication (excluding responses, which can follow the original message back)

[fregante]

Also addressed by #8