Bug 165412 – top.location.assign is undefined inside non-sandboxed iframe on different origin

• Status: RESOLVED
• Resolution: WONTFIX
• Component: DOM

[Mohammed Khatib]

top.location.assign is undefined inside an iframe. For example,
  
top: https://hello.com
  iframe: https://whatsapp.com
     script loaded from: https://whatsapp.com
        executes -> window.top.location.assign('https://whatever.com') // <- .assign is undefined and throws a security error
        executes -> window.top.location.replace('https://whatever.com') // <- .replace is NOT undefined and works as expected
        executes -> window.top.location.href = 'https://whatever.com' // <- works as expected


Errors thrown by .assign:
window.top.location.assign is not a function. (In 'window.top.location.assign(url)', 'window.top.location.assign' is undefined)
Blocked a frame with origin 'https://whatsapp' from accessing a frame with origin 'https://hello.com'. Protocols, domains, and ports must match.

The expected behavior is that .assign would still work in non-sandboxed iframes - similar to replace.

[Daniel Bates]

(In reply to comment #0)
> top.location.assign is undefined inside an iframe. For example,
>   
> top: https://hello.com
>   iframe: https://whatsapp.com
>      script loaded from: https://whatsapp.com
>         executes -> window.top.location.assign('https://whatever.com') // <- .assign is undefined and throws a security error

This is the correct behavior when accessing/calling location.assign() on a cross-origin Location instance as per <https://html.spec.whatwg.org/multipage/browsers.html#dom-location-assign>.

> [...]
> The expected behavior is that .assign would still work in non-sandboxed
> iframes - similar to replace.

No, this is not correct. See my above remark.

[Mohammed Khatib]

Thanks for following up on this. I filed another bug for replace/href assignment not able to navigate user to itunes links here: https://bugs.webkit.org/show_bug.cgi?id=165627