RESOLVED FIXED Bug 26520
Accessing a DOM node from a parent window in a child iframe moves the prototype to the child iframe and resets it in the parent window
https://bugs.webkit.org/show_bug.cgi?id=26520
Summary Accessing a DOM node from a parent window in a child iframe moves the prototy...
Paul Sowden
Reported 2009-06-18 15:17:25 PDT
In the test case we extend the prototype of HTMLInputElement to add a property "foo". In the child iframe I extend the prototype of HTMLInputElement to add a property "bar". In the child iframe we hook up an event listener to the parent window's body and access e.target. When clicking the submit button we should expect to see "foo", which is the property we added to the HTMLInputElement's prototype, but instead we see "undefined". Removing the line in the iframe which accesses e.target causes the alert to display "foo", as expected. It looks like when e.target is accessed in the child iframe it creates the HTMLElement DOM wrapper and this causes the prototypes from the parent window to be moved to the child iframe, then when we handle the onsubmit event in the parent window it lazyilly creates the HTMLElement DOM wrapper but with a blank prototype that now exists in the parent window. The extended prototypes are getting incorrectly moved between the two window objects. This looks like it could be related to bug 24795 but the testcase attached to that bug seems to work in the latest nightly so I suspect that it could actually be a different issue.
Attachments
Testcase for the main page (requires test-prototype-iframe.html as well) (241 bytes, text/html)
2010-02-26 20:32 PST, Paul Sowden
no flags
Testcase for the iframe (is loaded by the first testcase page) (219 bytes, text/html)
2010-02-26 20:33 PST, Paul Sowden
no flags
proposed patch (3.54 KB, patch)
2010-02-27 21:29 PST, Alexey Proskuryakov
darin: review+
Alexey Proskuryakov
Comment 1 2009-06-24 00:44:36 PDT
Confirming as a difference with Firefox.
Adam Barth
Comment 2 2009-06-24 01:48:11 PDT
This is a dup of another bug that I can't put my fingers on immediately. This is also related to a recent thread on webkit-dev.
Alexey Proskuryakov
Comment 3 2010-02-26 19:51:08 PST
The bug URL is no longer valid. Could you please attach the test case to the bug?
Paul Sowden
Comment 4 2010-02-26 20:32:30 PST
Created attachment 49673 [details] Testcase for the main page (requires test-prototype-iframe.html as well)
Paul Sowden
Comment 5 2010-02-26 20:33:16 PST
Created attachment 49674 [details] Testcase for the iframe (is loaded by the first testcase page)
Alexey Proskuryakov
Comment 6 2010-02-26 21:20:03 PST
Thanks! I can reproduce with Safari/WebKit 4.0.4, but this appears fixed with recent WebKit builds (I tried r55339).
Paul Sowden
Comment 7 2010-02-26 23:06:35 PST
For reference, I'm pretty sure this was fixed in r46444.
Alexey Proskuryakov
Comment 8 2010-02-26 23:34:38 PST
Maybe we need to land this test case then - r46444 didn't include tests. Re-opening for that.
Alexey Proskuryakov
Comment 9 2010-02-27 21:29:45 PST
Created attachment 49692 [details] proposed patch
Alexey Proskuryakov
Comment 10 2010-03-01 18:25:27 PST
Note You need to log in before you can comment on or make changes to this bug.