[whatwg] iframe sandbox attribute

[Adam Barth]

On Fri, Mar 30, 2012 at 12:22 PM, Ian Melven <imelven at mozilla.com> wrote:
> I agree that it's pretty likely folks won't be mutating
> this property very often - the HTML5 spec actually
> recommends against messing with the sandbox attribute dynamically at all :
>
> "Generally speaking, dynamically removing or changing the sandbox attribute is ill-advised,
> because it can make it quite hard to reason about what will be allowed and what will not."
> (which I also agree with. )
>
> that said, what do you think about the case Boris points out where
> myFrame.sandbox = myFrame.sandbox; can change the sandboxing
> of a frame ?
>
> In my opinion, both this and the case involving myOtherFrame.sandbox = myFrame.sandbox;
> are pretty non-intuitive - unless as Boris suggests, .sandbox is null for an iframe which
> hasn't had a sandbox attribute declared. A script author could use .present
> or .hasAttribute to work around this, but my concern is the potentially
> surprising behavior.

IMHO, it's better if the sandbox property behaves like other
properties rather than being magically different.  In these cases, the
result is more sandboxing than you might expect rather than less,
which is probably fine.

Adam


> ----- Original Message -----
> From: "Adam Barth" <w3c at adambarth.com>
> To: "Boris Zbarsky" <bzbarsky at mit.edu>
> Cc: whatwg at lists.whatwg.org
> Sent: Thursday, March 29, 2012 2:17:42 PM
> Subject: Re: [whatwg] iframe sandbox attribute
>
> I guess I don't see much value in using DOMSettableTokenList for the
> sandbox property.  I don't expect folks to mutate the property much.
> They're just likely to set it to a constant and be done with it.  The
> situation is very different for a property like className, where
> there's a strong use case for mutating.
>
> Adam
>
>
> On Mon, Mar 26, 2012 at 4:06 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> On 3/26/12 3:19 PM, Ian Hickson wrote:
>>>
>>> Changing it to a string doesn't affect that, though, does it?
>>
>>
>> Well, changing to a nullable string does affect it because doing something
>> like this:
>>
>>  myFrame.sandbox = myFrame.sandbox;
>>
>> is a no-op, as by all sane rights it should be....  More importantly,
>>
>>  myOtherFrame.sandbox = myFrame.sandbox;
>>
>> doesn't have weird surprising behavior if the attribute is something whose
>> value sanely distinguishes between the various possible sandbox values.
>>
>>
>>> We can certainly add an attribute to DOMSettableTokenList (or rather, a
>>> descendant, for use specifically with iframe.sandbox) that does the same
>>> as .hasAttribute(), e.g.:
>>>
>>>    iframe.sandbox.present
>>>
>>> ...or something, if that would help.
>>
>>
>> Would we also make the attribute readonly, then, and require that it be set
>> via the token list?  Otherwise, it seems like the snippets above would still
>> have pretty unexpected behavior.  But even then they might, since sets of
>> readonly props are just silently ignored.  :(
>>
>> -Boris