Since each content script is scoped to the domain of the |window| it is attached it cannot directly manipulate cross-origin frames and has to talk to separate content scripts attached to those frames. But securely talking to those other content scripts is fairly difficult. Attempting to use standard web APIs fails, e.g. top.postMessage("foo", "moz-extension://...") fails with the following error: > Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘moz-extension://...’) does not match the recipient window’s origin (‘https://www....’). Expected behavior: a) The message is sent anyway and can only be received by by the content script in the other frame b) the message's |origin| is set to postMessage's |targetOrigin| if it's sent from an expanded principal and received on an expanded principal and both principals subsume targetOrigin. In other words, when sending from a content script to a content script then both ends can be sure that only the content script was able to see it and not the page content.
Is this a regression?
Component: DOM → WebExtensions: Untriaged
Product: Core → Toolkit
IIUC what is being attempted here, runtime.sendMessage can be used.
Status: UNCONFIRMED → RESOLVED
Closed: Last year
Resolution: --- → INVALID
I can't scope sendMessage's target to a specific window, so it seems like it would be quite inefficient due to broadcasting every event.
Not sure why this was closed. This is definitely something we ideally want. runtime.sendMessage is harder to target and has higher latency. We should make it as easy as possible for extensions to do the Right Thing.
Status: RESOLVED → REOPENED
Component: Untriaged → General
Ever confirmed: true
Resolution: INVALID → ---
I ran into this while trying to port Shumway to WebExtensions, since it uses window.postMessage to send data back and from the different rendering iframes and, during startup, the content script of the embedding page.
You need to log in before you can comment on or make changes to this bug.