| Summary: | Accessing `window.frameElement` should not report error if parent is cross-origin | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Robert Knight <robertknight> |
| Component: | Frames | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | cdumez, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 15 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Robert Knight
2022-01-31 08:37:06 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.) 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.
|