[Webkit-unassigned] [Bug 47662] New: sputnik tests assume object property enumeration order is stable

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=47662

           Summary: sputnik tests assume object property enumeration order
                    is stable
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: xan.lopez at gmail.com


The tests located in fast/js/sputnik/Conformance/10_Execution_Contexts/10.2_Entering_An_Execution_Context/10.2.2_Eval_Code all basically do the same thing: go through the properties of the global object, once with a normal for ... in loop, and another time evaluating a string that has in it a for .. in loop. It records the property names and their order, and after it checks it got the same result in both runs.

These tests fail and are commented in many platforms (GTK+, Qt, Mac, Win). The reason is that in most ports ShowModalDialog is left undefined, and its ordering in the property enumeration changes between the first and second run. In a comment in the bug where showModalDialog was discussed and this issue argued about (https://bugs.webkit.org/show_bug.cgi?id=35350#c18) it was theorized this had something to do with using eval in the second time through, but this is actually not true. The simple attached testcase uses a normal for .. in loop two times, and the location of showModalDialog still differs between them. The reason is that many of the properties accessed in the first loop are cached, save for showModalDialog, and in the second loop JSC introduces them in the result array earlier than before. My, admittedly uninformed, reading of the spec tells me it's ok to do this, since the ordering of the properties is not guaranteed at all. If this is the case I think the test is 
 not correctly written, and we should either get rid of it or fix it somehow upstream and resync. I'm still opening this bug in case I understood something wrong or that some of the current JSC behavior is wrong, and to have some debate on the topic.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.