WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
235893
Accessing `window.frameElement` should not report error if parent is cross-origin
https://bugs.webkit.org/show_bug.cgi?id=235893
Summary
Accessing `window.frameElement` should not report error if parent is cross-or...
Robert Knight
Reported
2022-01-31 08:37:06 PST
Calling `window.frameElement` from an iframe with a cross-origin parent returns `null` in Chrome, Firefox and Safari. In Safari it additionally results in a console error with the text "Blocked a frame with origin $IFRAME_ORIGIN from accessing a frame with origin $PARENT_ORIGIN. Protocols, domains and ports must match." In Chrome/Firefox no such error is reported. The specification [1] just says that the access should return null in this situation, it doesn't mention this access being an error. It looks like this may relate to a standards change described in
https://github.com/whatwg/html/pull/266
. We came across this as our application had code that checked for null-ness of `window.frameElement` and then executed different code depending on whether the child frame can reach into the parent or not. Both cases are regarded as non-error scenarios in our context. [1]
https://html.spec.whatwg.org/multipage/browsers.html#dom-frameelement
Attachments
Add attachment
proposed patch, testcase, etc.
Sam Sneddon [:gsnedders]
Comment 1
2022-01-31 09:53:41 PST
Note this is only a message in the console; window.frameElement does return null in the cross-origin case as far as I can tell. There's nothing standardised about what does and doesn't get put in the console (as errors, warnings, or in any other form). I _believe_ (but I'm not totally sure!) that the current WebKit behaviour is to log in the console for any blocked cross-origin access. Do you think that logging when no exception is thrown is confusing, or that logging an error when no exception is thrown is confusing? (
http://wpt.live/html/browsers/windows/nested-browsing-contexts/frameElement.sub.html
covers this case, and we indeed pass all the tests.)
Robert Knight
Comment 2
2022-01-31 23:16:01 PST
I acknowledge the standard doesn't say anything about what gets logged in the browser console. I found it confusing though that a console error was logged even though no exception occurred and the code triggering the error was not doing something that the specs/MDN docs indicated as being deprecated or bad practice. The code in question looks something like: ``` if (window.frameElement) { // Execute some logic that makes use of information about the iframe // containing this document. } else { // Fallback for cross-origin case. } ``` While looking at this I found we also have some code that triggers the same error but from the other side, using the `iframe.contentDocument` property to test whether an iframe is same-origin.
Radar WebKit Bug Importer
Comment 3
2022-02-07 08:38:19 PST
<
rdar://problem/88573609
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug