Bug 26520

Summary:

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

Product:

WebKit

Reporter:

Paul Sowden <paul>

Component:

WebCore JavaScript

Assignee:

Alexey Proskuryakov <ap>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

abarth, ap, ggaren, gianni, kangax, sam

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

URL:

http://paulsowden.com/etc/webkit/test-prototype.html

Attachments:

Description	Flags
Testcase for the main page (requires test-prototype-iframe.html as well)	none
Testcase for the iframe (is loaded by the first testcase page)	none
proposed patch	darin: review+

Description Paul Sowden 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.

Comment 1 Alexey Proskuryakov 2009-06-24 00:44:36 PDT

Confirming as a difference with Firefox.

Comment 2 Adam Barth 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.

Comment 3 Alexey Proskuryakov 2010-02-26 19:51:08 PST

The bug URL is no longer valid. Could you please attach the test case to the bug?

Comment 4 Paul Sowden 2010-02-26 20:32:30 PST

Created attachment 49673 [details]
Testcase for the main page (requires test-prototype-iframe.html as well)

Comment 5 Paul Sowden 2010-02-26 20:33:16 PST

Created attachment 49674 [details]
Testcase for the iframe (is loaded by the first testcase page)

Comment 6 Alexey Proskuryakov 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).

Comment 7 Paul Sowden 2010-02-26 23:06:35 PST

For reference, I'm pretty sure this was fixed in r46444.

Comment 8 Alexey Proskuryakov 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.

Comment 9 Alexey Proskuryakov 2010-02-27 21:29:45 PST

Created attachment 49692 [details]
proposed patch

Comment 10 Alexey Proskuryakov 2010-03-01 18:25:27 PST

Test committed <http://trac.webkit.org/changeset/55396>.