A DOM use case that can't be emulated with direct proxies

David Bruant bruant.d at gmail.com
Fri Dec 14 02:47:15 PST 2012

Le 14/12/2012 11:01, Andreas Rossberg a écrit :
> On 13 December 2012 19:21, Mark S. Miller <erights at google.com> wrote:
>> On Thu, Dec 13, 2012 at 1:12 AM, David Bruant <bruant.d at gmail.com> wrote:
>>>> As you say, to remain viable, it
>>>> must be done quickly. From previous experience, I suggest that there's
>>>> exactly one way to get quick universal deployment: add a test to
>>>> test262 that fails when a browser's WindowProxy object violates this
>>>> normative part of the ES5 spec.
>>> I feel such a test would rather belong to the HTML DOM. But either way, I
>>> agree.
>> The spec that it violates is ES5.1. Therefore it will be
>> uncontroversial to put such tests into test262.
> I have to strongly disagree here. By this argument, we could put in a
> test for any JS extension in the world that potentially violates
> proper ES semantics. I think test262 should test ECMA-262, nothing
> else.
> In particular, consider that test262 currently is a headless test,
> i.e. no browser needed, a shell like d8 or jsc is enough to run it.
> Putting in browser-specific tests would put a _huge_ burden on all
> kinds of automated testing environments running this suite.
I still believe the tests belong to HTML DOM, but it wouldn't be absurd 
to test this inside of test262.
The invariants are an ES5 device. I think it makes sense for ES5 to say 
"we noticed that some platforms were defining host objects not 
respecting the invariants; here is how they were wrong". The invariants 
are a not-well-known and yet normative part of the spec. Offering some 
guidance in test262 on this part would be good I think.

I would organize things the following way: inside of the /test/suite 
     readme (explains why this directory is here and what the different 
subdirectories are for)
         readme (to explain how to run each test)

And if different platforms use ES5, but do not conform, platformSpecific 
subdirectories can be added to test the non-conforming host objects on 
the different platforms.
Each platform test can contain any sort of file, not just JS. For 
instance, in the case being discussed, it would make sense to create 
several HTML files some defining iframes, other defining iframe contents.

d8 or jsc would just have to skip the "platformSpecific" directory. I 
think it's a decent trade-off to explain how invariants should work on 
self-objects without polluting the test suite.

[cc'ing test262]


More information about the es-discuss mailing list