Re: Custom element lifecycle callbacks

On 1/9/15 7:14 AM, Anne van Kesteren wrote:
> Both parent and input need to be cloned in this case. While parent's
> callback runs it changes the type of input, at which point input's
> callback runs. So, yes.

OK.  So just to be clear, the type will be set before the input's 
cloning callback runs, yes?

> It's a bit unclear to me why "When an input element's type attribute
> changes state" does not sanitize this value

When the type changes it sanitizes the value of the input.  Though I see 
nothing in the spec to indicate this; I filed 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27791

But in this case the value is not set yet when the type changes.  Then 
the cloning callback runs and sets the value on the now-file-type input, no?

In particular, the current spec for <input> says:

   The cloning steps for input elements must propagate the value, dirty
   value flag, checkedness, and dirty checkedness flag from the node
   being cloned to the copy.

This is not conditional on the input type in any way, unlike .value 
sets.  So if we allow the type to change before the cloning steps run, 
the cloning steps need to be adjusted to deal with this situation.

And in particular, all cloning steps need to be carefully audited to 
deal with issues like this.

> or how cloning it makes it a security concern.

Because if the cloning steps in HTML are left as-is but run after script 
can change the type, then you can create a file input with an arbitrary 
value filled in.  Which is a security concern.

-Boris

Received on Friday, 9 January 2015 13:29:53 UTC