Bug 25079 – (needs test?) JS Arrays et al receive the wrong prototype

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[John-David Dalton]

First create sandboxed natives by creating an iframe and referencing its Array,
String, Date or other natives. When calling a method on the sandboxed native it
returns a document native instead of a sandboxed one.

Example:

window.Sandbox.Array.prototype.awesome = function() { };
var foo = new window.Sandbox.Array('a', 'b', 'c');
alert(typeof foo.awesome); // -> function
alert(typeof Array.prototype.awesome) -> undefined (correctly reports
undefined)
alert(typeof foo.slice(0).awesome) -> undefined (should be `function`)

Tested and fails on Safari 2.0 - 3.4 beta.
Chrome, IE, and Opera work correctly.

[Dan Trott]

This still appears to be an issue in Safari 4.0.5 (tested on Windows).

This is causing a lot of issues in our app which interacts with a child document which has been extended with the Prototype framework.

[Adam Barth]

Can you attach a version of your test case in HTML?  I don't understand what Sandbox is.  Also, have you tried a nightly build from http://nightly.webkit.org/?

[Dan Trott]

It seems that the issue I've been experiencing is not quite the same as the one reported by John-David.

I made a test that demonstrates my issue and tried it in the latest nightly, it's fixed.

I ran John-David's test in the latest nightly and the test still fails.

[John-David Dalton]

I have updated the test case. This is still an issue in Safari 5. With JavaScript frameworks like FuseJS using this technique it would be beneficial if Safari would fix this bug so it can perform as well as other browsers.

[Adam Barth]

Ok.  I understand now.  Your test case is about 10x more complex than it needs to be.  The issue is that object created via constructors are getting their prototypes from the current page whereas they should be getting their prototypes from the page that contained the constructors originally.  In the test case, the page that contains the constructors is detached, but it's unclear whether that's essentially to the issue.

[Adam Barth]

Created attachment 63058 [details]
Reduced test case

Here's a reduced test case.

[Adam Barth]

Probably something internal to JSC.

[John-David Dalton]

I noticed you changed the title to `JS Arrays` receive the wrong prototype. This is for any native object instance. The same thing can be seen for:

Sandbox.String.prototype.blah = 3;
var str = new Sandbox.String('x');
str.blah; // should be 3

[Oliver Hunt]

What do sandboxes have to do with this?  The testcase is simply using an iframe, i don't see any sign of the sandbox attribute?

[John-David Dalton]

@Oliver Hunt: "Sandboxed Natives" is the term I use for natives imported from an iframe, ActiveX object, or modified via the non-standard __proto__ property. The `Sandbox` object in the code snippets refers to the test case I have linked to.

[Adam Barth]

> What do sandboxes have to do with this?

Noting.

> The testcase is simply using an iframe, i don't see any sign of the sandbox attribute?

That's correct.

[Adam Barth]

(In reply to comment #11)
> > What do sandboxes have to do with this?
> 
> Noting.

Err.  "Nothing."

[Alexey Proskuryakov]

How is this related to bug 27088?

[Adam Barth]

> How is this related to bug 27088?

The difference in behavior is similar (prototypes get wired up to the wrong objects), but the fix will be different.  Bug 27088 is about JavaScript objects constructed in WebCore.  This bug is about JavaScript objects constructed in JavaScriptCore (e.g., via the Array and String constructors).

[John-David Dalton]

Just a heads up. The discussion of removing __proto__ over on the Mozilla bug tracker is related to this ticket. https://bugzilla.mozilla.org/show_bug.cgi?id=642500

Because of this bug part of the code I maintain will fall to __proto__. If this bug was fixed that would remove the strain and cause me to sleep better at night. This seems to be a Safari only issue.

[John-David Dalton]

Just confirmed via the `Reduced test case` that this bug still exists in WebKit Nightly r80840 built on March 11, 2011. Can the status be changed to `confirmed`?

[Sam Weinig]

This is now fixed.

[Alexey Proskuryakov]

Should we land Adam's test case now?

[Gavin Barraclough]

Test case landed in r89111.