I have an iframe where I'm creating an Array with in the parent's context via new parent.Array(). I now call a function in the parent window passing this array. When the parent function receives this argument, it fails the instanceof test. I understand that passing "new Array()" from the iframe to parent will cause the "instanceof Array " test to fail in the parent because the contexts of the two are different, but in this case I am creating a array from the parent context itself yet if fails the "instanceof Array" test. Below is a simple testcase illustrating the problem. This test runs fine on IE, Firefox and Opera but fails on Safari only. parent.html <html> <head> </head> <body> <script type="text/javascript"> function isArray(arr) { alert(arr instanceof Array); } </script> </body> <iframe src="child.html"></iframe> </html> child.html <html> <head> </head> <body> <script type="text/javascript"> function test() { var arr = new parent.Array(); parent.isArray(arr); } </script> <button onclick="test()">Array Test</button> </body> </html>
Created attachment 26690 [details] child.html
Created attachment 26691 [details] parent.html (test case)
Confirmed with WebKit nightly build r39872.
(In reply to comment #3) > Confirmed with WebKit nightly build r39872. Confirmed the test case alerts "true" in Firefox 3, but alerts "false" in WebKit/Safari.
FYI, this is a problem in Firefox 4 now too (test case alerts "false")
Created attachment 87001 [details] Patch
Attachment 87001 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/API/JSObjectRef.cpp'..." exit_code: 1 Source/JavaScriptCore/runtime/JSCell.h:38: Code inside a namespace should not be indented. [whitespace/indent] [4] Total errors found: 1 in 34 files If any of these errors are false positives, please file a bug against check-webkit-style.
Attachment 87001 [details] did not build on qt: Build output: http://queues.webkit.org/results/8256011
Attachment 87001 [details] did not build on win: Build output: http://queues.webkit.org/results/8256017
Created attachment 87186 [details] Patch
Attachment 87186 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1 Source/JavaScriptCore/runtime/JSCell.h:38: Code inside a namespace should not be indented. [whitespace/indent] [4] Total errors found: 1 in 38 files If any of these errors are false positives, please file a bug against check-webkit-style.
Attachment 87186 [details] did not build on win: Build output: http://queues.webkit.org/results/8273473
Created attachment 87200 [details] Patch
Attachment 87200 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1 Source/JavaScriptCore/runtime/JSCell.h:38: Code inside a namespace should not be indented. [whitespace/indent] [4] Total errors found: 1 in 39 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 87200 [details] Patch r=me
Committed r82173
This caused assertion and test failures in run-javascriptcore-tests on Windows. Here's the assertion: ASSERTION FAILED: isCell() > JavaScriptCore.dll!JSC::JSValue::asCell() Line 559 + 0x30 bytes C++ JavaScriptCore.dll!JSC::asObject(JSC::JSValue value={...}) Line 393 + 0x8 bytes C++ JavaScriptCore.dll!JSC::asInternalFunction(JSC::JSValue value={...}) Line 65 + 0x12 bytes C++ JavaScriptCore.dll!JSC::constructDate(JSC::ExecState * exec=0x012201a0, const JSC::ArgList & args={...}) Line 124 + 0x3e bytes C++ JavaScriptCore.dll!JSObjectMakeDate(const OpaqueJSContext * ctx=0x012201a0, unsigned int argumentCount=1, const OpaqueJSValue * const * arguments=0x0012fdd8, const OpaqueJSValue * * exception=0x00000000) Line 171 + 0x22 bytes C++ testapi.exe!main(int argc=1, char * * argv=0x013c99d8) Line 1304 + 0x19 bytes C++ testapi.exe!__tmainCRTStartup() Line 597 + 0x17 bytes C kernel32.dll!_BaseProcessStart@4() + 0x23 bytes I'm rolling out this patch in bug 57333.
I guess this can be resolved again since Oliver fixed the Windows issues.