Bug 47662 - sputnik tests assume object property enumeration order is stable
Summary: sputnik tests assume object property enumeration order is stable
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-14 04:37 PDT by Xan Lopez
Modified: 2022-07-31 02:55 PDT (History)
10 users (show)

See Also:


Attachments
properties.html (756 bytes, text/plain)
2010-10-14 04:38 PDT, Xan Lopez
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2010-10-14 04:37:31 PDT
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.
Comment 1 Xan Lopez 2010-10-14 04:38:18 PDT
Created attachment 70726 [details]
properties.html

Testcase.
Comment 2 Xan Lopez 2010-10-14 04:38:54 PDT
(In reply to comment #1)
> Created an attachment (id=70726) [details]
> properties.html
> 
> Testcase.

Note that the testcase will fail only in WebKit browsers that have showModalDialog unimplemented.
Comment 3 Ahmad Saleem 2022-07-31 02:36:55 PDT
In Safari 15.6 on macOS 12.5 - it does pass which has showModalDialog support but it also pass in Chrome Canary 106 and Firefox Nightly 105 - which don't have the support.

I assume with showModalDialog() support gone in future Safari, it will also work same as other browsers and pass.

JSFiddle - https://jsfiddle.net/q23p7gya/show

If we take assumption that it will work after the support is gone similar aligned with other browsers, we can close this right now or else we can revisit this after release version of Safari with support gone to confirm that the test case is working as intended and then close this bug.

Any thoughts?