(Restricting view for now, since this is partially motivated by issue 693695)
Currently, binding security checks are all based around the concept of frame. However, this is problematic as when a DOMWindow is detached, the connection back to the frame is broken. This makes it impossible to perform security checks, so we must fail the access--but if we throw an exception, it incorrectly causes a bunch of same-origin detached accesses to also fail. See https://codereview.chromium.org/2705783004/ for an example.
Instead, we should change canAccessFrame() to canAccessWindow(). The biggest obstacle to doing this is the Location object, which is currently associated with Frame. However, the Location member of DOMWindow is reset on detach / when a new DOMWindow is installed to prevent it from using a stale frame... rather than doing that, we should just be associating it with the Window object itself. This is what the spec actually requires anyway.
From https://whatwg.org/C/browsers.html#the-location-interface:
Each Window object is associated with a unique instance of a Location object, allocated when the Window object is created.
http://ithildin.com/tests/window/different-location.html is a quick test to verify this. Edge, Firefox, and Chrome all fail this test: Firefox and Chrome don't keep the same Location object when the Window object is reused, while Edge always uses the same Location object.
Once Location is associated with Window, then we can update the security checks to be based on Window, and we can remove the exceptions for detached frames.
Comment 1 by bugdroid1@chromium.org
, Feb 20 2017