W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: WebIDL and prototype chains

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 8 Aug 2009 21:29:57 -0700
Message-ID: <7789133a0908082129t2404134em1fff070872068524@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>
On Fri, Aug 7, 2009 at 5:51 PM, Ian Hickson<ian@hixie.ch> wrote:
> How should I address this for HTML5?

We talked over several option in #whatwg.  Here's something that might
make sense.  The approach below is designed to allow for robust
implementation and to isolated the "magical" properties in the window

Principle: Two distinct origins should have distinct JavaScript object
graphs.  The only point of contact between the JavaScript objects of
different origins should be window objects (or, more precisely,
WindowProxy objects).


1) When a script gets a property from a same-origin window object, the
script gets the same object as the page itself gets.

2) When a script gets a property from a cross-origin window object,
the script gets a *new* object with the appropriate interface.
  a) This new object is created in context of the accessing script
(i.e., the current lexical scope).  That means it gets a prototype
chain as appropriate for the accessing script.
  b) If two scripts from the same context access the same property,
they get the same object.  That is, we cache these newly created
objects per accessing window.  (They will likely be garbage collected
with that window as well.)


1) Suppose property foo is visible across origins and a script changes
it's own window.foo property in some way.  That change is not visible
to cross-origin viewers (because they get a fresh instance of whatever
the foo object originally was.)

Note: This behavior matches Firefox but differs from IE.  In IE,
cross-origin viewers tend to see the value |undefined| when viewing
properties that have been modified by the page.  This causes minor
security issues.

2) If two scripts from two same-origin windows get some property from
the same cross-origin window, the values they obtain will not be ===.
This is to avoid having different behavior based on which script
accesses the property first.

3) If one script grabs some property from a cross-origin window and
then later because same-origin with that window (e.g., via
document.domain tricks), then that script will get a different object
(the "real" one) if it access the property again.

Received on Sunday, 9 August 2009 04:31:02 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC