fix(webview): support input for elements inside cross-origin <iframe>#41463
fix(webview): support input for elements inside cross-origin <iframe>#41463dcrousso wants to merge 2 commits into
<iframe>#41463Conversation
…`<iframe>` leverage `elementFromPoint`, `getBoundingClientRect`, and `getComputedStyle` to manually compute the offsets of each ancestor `<iframe>` also use existing infrastructure of `error:notconnected` to tell the caller to re-resolve the element in the parent context
dcrousso
force-pushed
the
fix-WKWebView-cross-origin-iframe-input
branch
from
2bac9db to
4d7c0b8
Compare
Test results for "MCP"3 failed 7377 passed, 1122 skipped Merge workflow run. |
Test results for "tests 1"2 failed 3 flaky49071 passed, 1142 skipped Merge workflow run. |
| return { target, frame: null, doc: null, x, y }; | ||
| const frame = target as HTMLIFrameElement | HTMLFrameElement; | ||
| const frameRect = frame.getBoundingClientRect(); | ||
| const frameStyle = frame.ownerDocument.defaultView!.getComputedStyle(frame); |
There was a problem hiding this comment.
This (and in other places) looks like a cross origin reach?
There was a problem hiding this comment.
the ownerDocument is the ancestor of the <iframe> (as opposed to the contentDocument which is inside the <iframe>)
this is a replacement for a direct window.getComputedStyle(frame) which may not work since the window could be the wrong object if at this point the context is already inside an <iframe>
| if (active && (active.localName === 'iframe' || active.localName === 'frame')) { | ||
| let inner: Element | null = null; | ||
| try { | ||
| const doc = (active as HTMLIFrameElement | HTMLFrameElement).contentDocument; |
There was a problem hiding this comment.
I still don't think the bulk of this change makes sense. Each frame has its own injected script with its own document and window object, available on the injected script itself. They are only ones, you can't switch between them in the injected script.
2 participants
this is layered on top of #41437