Bug 80205 – window.frameElement should return null if there isn't the Element for the browsing context container

• Component: DOM
• Status: RESOLVED FIXED

[Syoichi Tsuyuhara]

see http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#navigating-nested-browsing-contexts-in-the-dom .

>window . frameElement
>Returns the Element for the browsing context container.
>
>Returns null if there isn't one.
>
>Throws a SecurityError exception in cross-origin situations.

Internet Explorer 9.0.5, Firefox Nightly 13.0a1(buildID 20120302031112), Opera Next 12.00 alpha(build 1317) return null, but WebKit r109602 returns undefined, on Windows 7 Home Premium SP1 64bit.

[Kentaro Hara]

(In reply to comment #0)
> see http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#navigating-nested-browsing-contexts-in-the-dom .
> 
> >window . frameElement
> >Returns the Element for the browsing context container.
> >
> >Returns null if there isn't one.
> >
> >Throws a SecurityError exception in cross-origin situations.
> 
> Internet Explorer 9.0.5, Firefox Nightly 13.0a1(buildID 20120302031112), Opera Next 12.00 alpha(build 1317) return null, but WebKit r109602 returns undefined, on Windows 7 Home Premium SP1 64bit.

Makes sense. I am making a bug-fix patch...

[Kentaro Hara]

Maybe this is not only a problem of frameElement. contentDocument also requires null if the access is not allowed.

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#dom-iframe-contentdocument

It would make sense to fix code generators to return null when shouldAllowAccessToNode() fails.

[Kentaro Hara]

Created attachment 131764 [details]
Patch

[Hajime Morrita]

(In reply to comment #3)
> Created an attachment (id=131764) [details]
> Patch

- Does the change covers all expectations? I wonder why there is no expected.txt for mac changed.
> Maybe this is not only a problem of frameElement. contentDocument also requires null if the access is not allowed.
Why not cover this?

[Kentaro Hara]

Created attachment 131775 [details]
Patch

[Kentaro Hara]

(In reply to comment #4)
> - Does the change covers all expectations? I wonder why there is no expected.txt for mac changed.
> > Maybe this is not only a problem of frameElement. contentDocument also requires null if the access is not allowed.
> Why not cover this?

- The test of frameElement is cross-frame-access-frameelement.html. I updated cross-frame-access-frameelement-expected.txt.
- Another test of frameElement is cross-frame-access-put.html. This is skipped on mac and other ports, and I just updated platform/chromium/.../cross-frame-access-put-expected.txt.
- The test of contentDocument is local-iFrame-from-remote.html. I didn't update expected.txt because there is no change in the test result.

[WebKit Review Bot]

Comment on attachment 131775 [details]
Patch

Clearing flags on attachment: 131775

Committed r110667: <http://trac.webkit.org/changeset/110667>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Syoichi Tsuyuhara]

I confirmed this bug fix on WebKit r110696. Thanks, Kentaro Hara, Hajime Morrita, Adam Barth!

[Alexey Proskuryakov]

This patch fixed both JSC and v8, but cross-platform results in http/tests/security/cross-frame-access-put-expected.txt have not been updated: bug 82751. Neither have been Qt results.

Was there a reason to keep old cross-platform results?

[Adam Barth]

> Was there a reason to keep old cross-platform results?

Probably not.  They likely need to be updated to show the new behavior.