Simulator extension receives the embedder's origin as parentOrigin, not the editor's — breaks host→simx messaging when the editor is embedded cross-origin

[Amerlander]

Describe the bug

When the editor starts a simulator extension (simx) iframe, it passes the editor's embedder origin as the simx's parentOrigin (options.parentOrigin) instead of the editor's own origin. A simx that validates the origin of incoming postMessages against that value (e.g. jacdac's IFrameBridgeClient) then rejects every message the editor forwards to it whenever the editor is embedded cross-origin in controller mode - because those messages arrive with the editor's origin, which never matches the embedder origin the simx was told to trust. Net effect: nothing the host sends reaches the simulator extension.

To Reproduce

Scenario: a host app embeds the editor cross-origin, owns the device connection (e.g. BLE/USB), and relays frames to/from the editor via postMessage.

1. Embed the editor in an iframe on a different origin with controller=2 and parentOrigin=<host origin> (so the editor whitelists the host).
2. Run a project that activates a simulator extension whose iframe validates the origin of inbound messages against its parentOrigin (the Jacdac simx / IFrameBridgeClient does this).
3. From the host, post { type: "messagepacket", channel: "jacdac", broadcast: true, data } to the editor iframe.
4. The simx never receives it; its origin check drops it. (It works when the editor is not embedded, because parentOrigin is then undefined and the simx falls back to accepting any origin, masking the bug.)

Expected behavior

The simulator extension receives the messages the editor forwards to it (so a host-bridged device shows up). Since the simx's parent window is the editor, it should be given the editor's own origin (window.location.origin) as parentOrigin.

Screenshots

N/A --- the symptom is the simx receiving no forwarded frames (its origin check rejects them).

Desktop:

• OS: Windows 11
• Browser: Chrome 149
• Version: pxt-core 12.3.7 (behavior identical on master)

Smartphone: N/A

Additional context

In the simulatorExtension start path it does:

pxt/pxtsim/simdriver.ts

Line 429 in 3aaeddb

url.searchParams.set("parentOrigin", encodeURIComponent(this.options.parentOrigin));

i.e. the embedder (grandparent) origin, where the simx's actual parent is the editor.

One-line fix candidate: pass window.location.origin instead of this.options.parentOrigin (correct standalone and embedded). Happy to open a PR; open to a different approach if you'd prefer to solve it another way.

[Amerlander]

@abchatra could you have a look at this? Jörn already reached out to Jacqueline last week by email regarding this issue.

Here is a quick reproduction of why this is a real world issue for us. It requires a Calliope mini 3 and some Jacdac hardware connected via USB.

1. Open: https://campus.calliope.cc/room/puzzle-petunia-loop
2. Enter any name and any password (> 8 characters):
3. Click the Calliope-Icon button in the top right corner and select "Verbinden" (Connect) via USB to connect a Calliope mini with Jacdac hardware:
4. A MakeCode program with the Jacdac extension should already be open.
5. Click on "Download" in MakeCode to transfer the file to the hardware.
6. Result: The simulator does not accept the communication that we forward from the USB connection via our host application, likely due to the origin mismatch described in the issue.

How we implemented the host-side bridge

(so you can confirm we're using the simx contract correctly):

Topology:
campus embeds the editor cross-origin as a controller=2 iframe and owns the physical device (BLE/USB) via our connection widget. Because controller mode gives the iframe exclusive device ownership, the simx cannot open its own Jacdac transport — the host relays frames over postMessage.

Relay contract (both directions):
{ type: "messagepacket", channel: "jacdac", broadcast: true, data: <raw Uint8Array> }
We send data as a raw Uint8Array (not base64), and we do not set sender on device→editor frames, so IFrameBridgeClient's bridgeId loop-prevention doesn't drop them. We post to the editor origin, never "*".

Gate 1 (solved on our side):
we pass parentOrigin=<host origin> on the editor URL so the editor's SimulatorDriver._allowedOrigins whitelists our relayed frames. Confirmed on hardware: device → widget → host → editor works in both directions.

The only remaining broken hop is editor → simx, which is the bug in this issue: pxt stamps the simx URL's parentOrigin with options.parentOrigin (our grandparent/host origin), but the simx's real parent is the editor, and pxt re-broadcasts our frames from the editor window — so the Jacdac simx's origin check rejects them (editor origin ≠ host origin).

We've verified every hop except that last one, so we're confident the remaining gap is simdriver.ts:427-429. The one-line candidate (window.location.origin instead of options.parentOrigin) fixes it for both standalone and embedded — but if you'd prefer a different approach, we're happy to follow your lead and open the PR accordingly.

[thomasjball]

I asked Eric Anderson (@humanapp) to look at this as he created the simx framework.