Re: Multiple globals and direct/indirect eval

On Fri, Mar 4, 2011 at 5:53 AM, David Bruant <bruant@enseirb-matmeca.fr>wrote:

> [Adding WhatWG and public-script-coord (WebIDL) to the discussion.
> Discussion is ongoing :
> - Start of thread :
> https://mail.mozilla.org/pipermail/es-discuss/2011-March/012915.html
> - Strawman by Dave Herman:
> http://wiki.ecmascript.org/doku.php?id=strawman:multiple_globals )]
>
> -------------------
> Hi,
>
> I am wondering if ECMAScript is the right "place" to standardize this.
> Web browsers face multiple global object via a mecanism which isn't
> under the ECMAScript scope (namely HTMLIFrameElements
> (
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#htmliframeelement
> )
> which aren't even DOM but HTMLDOM-specific).
> Other ECMAScript implementations could face the issue of having several
> globals but with other non-HTMLDOM use cases. For that reason, I think
> it'd be dangerous for ECMAScript to standardize anything on the topic.
>

Hi David,

In general, if it is relevant to JS independent of hosting environment,
i.e., applicable outside the browser, then it should be in ECMA rather than
w3c/whatwg. For co-existence of multiple globals[1], as caused for example
by heap sharing among same-origin iframes, most of the problematic language
issues, such as the "eval" ambiguities Jeff raises, should be independent of
hosting environment or the means by which multiple globals are created.

[1] or multiple "contexts" -- I agree with DaveH that we need better
terminology!

OTOH, the so-called "semantics" of origins and co-existence of cross-origin
globals should be kept on the w3c/whatwg side, as it is browser specific and
should not pollute the rest of the language.



>
> To answer Jeff Walden's final questions, in my opinion, WebIDL would be
> a way better place to standardize this. ECMAScript could at most provide
> guidelines for ECMAScript implementors who would have to face this issue
> (gathering feedback and experience from implementations).
>

I certainly agree that there needs to be a better interface boundary
between w3c/whatwg specs and ECMA specs. Too many issues -- like the
semantics of multiple globals -- fall in the gaps between the two
organizations. The WebIDL's JS binding and public-script-coord are good
places to work out these boundary issues. WebIDL, WebIDL's JS binding, and
ES-next should co-evolve so that the rest of the w3c/whatwg specs ideally
interface to JS only through WebIDL, and WebIDL's JS binding ideally depends
only on standard elements of ES-next. Of course, there will always be a need
to accommodate some special cases that can't be specified that way, like the
"semantics" of cross-origin heap sharing.

My main regret in saying this is that WebIDL, having evolved from Corba IDL,
is notationally almost pessimal for encouraging good JS interface design. We
have all been suffering the consequences of that. I fear that WebIDL, and
its entrenched place within the w3c/whatwg API design process, dooms us to a
continual flood of browser APIs hostile to JS programmers.



>
> Cheers,
> David
>
>
>
> Le 03/03/2011 23:39, Jeff Walden a écrit :
> > A few months back I noticed an interesting interaction between how
> > direct eval is defined and multiple globals.  What happens if, in one
> > global, you call an eval from another global as if it were a direct eval?
> >
> >   var indirect = otherGlobal.eval;
> >   eval = indirect;
> >   print(eval("this") === this);
> >   print(indirect("this") === this);
> >
> > Standards currently don't say what should happen here because it's
> > multiple globals, so what should this do?  IE9 and Opera print false
> > both times for this.  Firefox prints true, then false -- but only if
> > the global and otherGlobal are from the same origin (so on pages with
> > the same scheme/host/port, more or less).  If they're from different
> > origins (but have set document.domain to the same value) Firefox too
> > prints false.  Chrome and Safari throw an EvalError calling another
> > window's eval (for both "direct" and indirect calls) without that
> > window as |this| for the call.
> >
> > The Chrome/Safari behavior would resurrect the vestigial EvalError, so
> > I don't think it makes sense.  It also contradicts the specification
> > of the steps in the definition of the eval function.  Firefox's
> > behavior is inconsistent and seems not amenable to host-agnostic
> > specification as ECMA would require.  Thus we are left with the
> > IE9/Opera behavior, which seems sensible and natural to me: an eval
> > function should always act in the context of the global from which it
> > came.
> >
> > What needs to be done to standardize this behavior?  And more
> > generally, what needs to be done to begin standardizing multiple
> > globals in ECMAScript, including issues like this one?
> >
> > Jeff
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM