In supporting browsers (Chrome, Safari, Edge, Firefox), third-party script loaded in an IFRAME that wraps EventTarget.prototype.addEventListener will lose track of the context of this, and will incorrectly bind the handler to its own IFRAME (instead of top).
Reproducible Case
To reproduce the issue, go here with the console open.
Without the fix, you will only see only 2 handlers fire:
first load handler fired
second load handler fired
Because history.js basically unbinds the window.addEventListener method, this passed to the _addEventListener.apply call will be the inner IFRAME (should be === top), and the load listener will be bound to the wrong window.
In supporting browsers (Chrome, Safari, Edge, Firefox), third-party script loaded in an IFRAME that wraps
EventTarget.prototype.addEventListener
will lose track of the context ofthis
, and will incorrectly bind the handler to its own IFRAME (instead oftop
).Reproducible Case
To reproduce the issue, go here with the console open. Without the fix, you will only see only 2 handlers fire:
To see the fix in action, go here. You will see:
Why this happens
in
history.js
:in an IFRAME:
developer code in
top
:Because
history.js
basically unbinds thewindow.addEventListener
method,this
passed to the_addEventListener.apply
call will be the inner IFRAME (should be=== top
), and theload
listener will be bound to the wrongwindow
.