Re: CSP 1.1 DOM design

On Mon, Nov 5, 2012 at 2:19 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 11/5/12 5:32 AM, Alex Russell wrote:
>
>> Other binding languages don't matter, but OK.
>>
>
> They can if you care about your DOM implementation being usable with more
> than one JS implementation...


I'm not saying that it's not valuable to have clarity. Only that if we spec
this in ES semantics (one way or the other), that's enough. We don't need
to spoon-feed this to Java, Dart, etc.


>  Read-only when vended from document.securityPolicy, right?
>>
>
> That's a good question.
>
> If you want to allow writing to these things sometimes but not others
> while making it look like normal ES semantics, things are a bit complicated
> because of strict mode.


Why strict mode? I'm not sure that matters.


>  Your best bet is to actually use separate interfaces for the readonly and
> writable versions at that point, unless WebIDL is somehow changed to allow
> this.


+heycam

Cameron: my view here is that the document.securityPolicy would be defined
as a getter that returns a Proxy (in ES6 terms) and that the proxy would
enforce the read-only invariants. It would be proxying for a "naive"
SecurityPolicy object.


>      Another thing to think about is whether reportURIs should really be
>>     an IDL array (which does NOT produce a JS array on the JS side, so
>>     it really depends on the expected use cases).
>>
>> I'll advocate for a JS array wherever we surface an array-like
>> collection.
>>
>
> So WebIDL has a concept of pass-by-value which will return a JS array (as
> in, create a new array and return it).
>
> There is no way to return a JS array that points directly into the stored
> state of an object in WebIDL right now.  Again, because we want to allow
> implementing the DOM in a language other than JS while remaining sane.


Sane for whom? ;-)


>  It's long past time that we stopped shitting on users with
>> ad-hoc collection types. If you want it read-only, vend an ES6 proxy. We
>> can figure out later how to say that in WebIDL (not that it actually
>> matters, IMO).
>>
>
> It certainly matters to me as an implementor.  Storing random JS arrays in
> my C++ code without leaking is a huge pain.  It's an even huger pain for
> WebKit, as I understand, to the point where they have vetoed specs that
> would require them to do that sort of thing.
>
> So I would like us to be very clear on exactly what behavior we're after
> here, as a basic prerequisite, before we start trying to figure out how
> spec it and implement it.  Because it really truly does matter if we want
> it to actually happen.


The goal of language fidelity isn't some abstract notion. It's good that
we've got Array.prototype on the prototype of this collection, and there is
TC39 work to do to make sure that if it's a subtype of some form, that it's
sane. Allen has made the best shot at this so far:

http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation

That said, WebIDL can do magic. If it's doing magic, it should do magic on
behalf of JS users today, even when JS isn't sane enough to explain it all.
This isn't the same as undefined behavior.