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.
(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...
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.
Created attachment 131764 [details] Patch
(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?
Created attachment 131775 [details] Patch
(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.
Comment on attachment 131775 [details] Patch Clearing flags on attachment: 131775 Committed r110667: <http://trac.webkit.org/changeset/110667>
All reviewed patches have been landed. Closing bug.
I confirmed this bug fix on WebKit r110696. Thanks, Kentaro Hara, Hajime Morrita, Adam Barth!
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?
> Was there a reason to keep old cross-platform results? Probably not. They likely need to be updated to show the new behavior.