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.
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.
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/?
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.
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.
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.
Created attachment 63058 [details] Reduced test case Here's a reduced test case.
Probably something internal to JSC.
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
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?
@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.
> 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.
(In reply to comment #11) > > What do sandboxes have to do with this? > > Noting. Err. "Nothing."
How is this related to bug 27088?
> 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).
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.
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`?
This is now fixed.
Should we land Adam's test case now?
Test case landed in r89111.