[angelix]

Why

The bridge object is installed in every frame (forMainFrameOnly:NO on macOS, INJECT_ALL_FRAMES on Linux), so any frame a page embeds can call the same IJsMessageHandlers as the page itself. A handler has no way to tell the two apart: JsMessage carries only callbackId, methodName and params, all of which the caller writes.

That matters for any handler that acts on the caller's authority, such as one that shows a permission prompt or returns account data: a third-party frame (an ad, an embedded widget) can make the call and it looks like the page made it.

What

JsMessage gains sender: JsMessageSender?:

data class JsMessageSender(val origin: String?, val isMainFrame: Boolean)

• It is filled by the native side, never from the page's JSON. A unit test covers a page that sends its own "sender" field.
• origin is serialized like window.origin: scheme://host[:port], or "null" for an opaque origin. It is null (no string) where the engine does not report one.
• sender is null where nothing is known about the sender, so existing handlers are unaffected and a handler that needs it can refuse a null.

	message from the page	message from a frame
macOS	origin, main frame	origin, not main frame
Linux	origin, main frame	origin, not main frame
Windows	no origin, main frame	not delivered

Desktop backends report it through a new NativeWebView.drainIpcMessagesWithSender(), whose default keeps every sender null. Android, iOS and Wasm are unchanged.

JsMessage is a data class, so the added constructor parameter (defaulted) is source compatible but changes the constructor/copy signature for already-compiled callers.

macOS

From WKScriptMessage.frameInfo (securityOrigin, isMainFrame).

Linux

WebKitGTK's script-message-received hands over the value only, so there is nothing to read a sender from. The window.ipc shim now passes each message to a relay script that runs in every frame in a script world of its own (webkit_user_script_new_for_world, handler registered with register_script_message_handler_in_world). Page scripts share the DOM with it but none of its JavaScript objects, so they can neither call that handler nor change what the relay reads: it stamps each message with window.origin and window.top === window of its own frame. A page reaches only its own frame's relay, through an event on its window, which a document of another origin cannot dispatch. WebKit starts the scripts of the two worlds in no fixed order, so a message sent before the relay has started in a document waits in the shim for it.

A message that does not come through the relay has no sender: one posted to webkit.messageHandlers.ipc directly, or sent between a page's document.open(), which removes the relay's listener, and the document the page then writes (WebKit runs the document-start scripts again there, and the sender is back).

Windows

ICoreWebView2::WebMessageReceived is documented for the top-level document, and a frame's chrome.webview.postMessage goes to ICoreWebView2Frame2::WebMessageReceived. I checked what happens when nothing subscribes to the frame's event, which is how this backend works: on windows-latest the messages of srcdoc, sandboxed, data: and nested frames never reached the view's handler. So every bridge message is the main frame's and is reported as such.

The origin is left out. get_Source is a URL: it read about:blank for a data: page and for a data: frame, and about:srcdoc for srcdoc frames whether sandboxed or not, and a URL cannot say that a document is sandboxed into an opaque origin.

Verify

./gradlew :e2e-desktop:run:

• macOS 27 (arm64): 74 passed, 0 failed, 2 skipped (B14 is Windows only; R01, window hidden).
• Linux (Ubuntu 24.04 arm64, WebKitGTK 2.52.6, Xvfb): 75 passed, 0 failed, 1 skipped (B14).
• Windows (windows-latest): 72 passed, 0 failed, 4 skipped (B12, B13, B15 and B17 are for the engines that report an origin). The suite does not complete on main on Windows (e2e-windows hangs in :e2e-desktop:run and times out after 45 min #54), so this ran with the two Windows commits of Fix e2e-windows (#54), a second WebView in a window (#55), and the CI workflow #71 applied to this branch. With the Windows change taken out, B14 fails there with senders={main=null, main-again=null}.

Cases:

• B12: a call from the page reports https://suite.local, main frame (macOS, Linux).
• B13: a call from a sandboxed srcdoc frame reports origin null, not main frame (macOS, Linux).
• B14: a sandboxed frame calls the bridge and tells its page; only the page's own calls arrive, each as the main frame's (Windows).
• B15: a sandboxed frame tries each way it has to send as the page that embeds it (the relay's handler, the relay's event on top, the embedder's ipc, a message that names its own sender); only its own messages arrive, as the frame's (macOS, Linux). With the relay moved into the page's world, this case fails with the forged message reported as https://suite.local, main frame.
• B16: bridge calls on both sides of document.open() arrive (desktop).
• B17: the suite view now has an init script that calls the bridge at document start; that call reports https://suite.local, main frame (macOS, Linux). On Linux it is the call that has to wait for the relay.

./gradlew :webview-compose:jvmTest passes. The Android, Wasm and iOS (simulator) targets compile; I did not run them.

Replies

Separately from this PR: callbacks are delivered with evaluateJavaScript into whatever document is loaded when the handler answers, and callback ids restart at 0 in every document, so a reply can land in a later document's callback. WKScriptMessageHandlerWithReply, ICoreWebView2Frame2::PostWebMessageAsJson and register_script_message_handler_with_reply (2.40) each bind a reply to the asking document. Happy to follow up if that is wanted.