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

Mark Miller erights at gmail.com
Fri Dec 14 09:12:52 PST 2012


On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 14 December 2012 16:54, Mark Miller <erights at gmail.com> wrote:
> > Regarding what Andreas said and what Alex +1ed, we already have
> precedent.
> > We already argued through this precedent in committee and agreed. I like
> > David's suggestion about how to organize these tests.
>
> Hm, unless you are talking about intl402, I wasn't aware of that.
> What's the precedent?
>

I will find it when I have time. If anyone else finds it first, please post
a link. Thanks.


>
> If the non ES tests are separated properly then it's probably less of
> an issue, though I still prefer that such tests are under a different
> umbrella. Just to make clear that they are not actually testing ES
> engines.
>
> That is, I'd much rather have a structure like (modulo details of naming):
>
> estests/
>   test262/
>     ch*/
>   intl402/
>   platforms/
>

The violation is a violation of the normative ES-262 5.1 spec. Host objects
as exposed to ES are part of the TCB, and constrained by the ES spec. The
ES spec is does not just constrain ES engines. If you want to make a
separate engines/ subdirectory of test262/ and move all the engine-only
tests there, I would not object. But I also would not recommend bothering.



>
> /Andreas
>
>
> > On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell <slightlyoff at google.com>
> > wrote:
> >>
> >> +1. What Andreas said.
> >>
> >>
> >> On Friday, December 14, 2012, Andreas Rossberg wrote:
> >>>
> >>> 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.
> >>>
> >>> /Andreas
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> >
> >
> > --
> > Text by me above is hereby placed in the public domain
> >
> >   Cheers,
> >   --MarkM
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121214/f308f006/attachment.html>


More information about the es-discuss mailing list