RE: Custom element lifecycle callbacks
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Fri, Jan 9, 2015 at 3:30 AM, Adam Klein ad...@chromium.org wrote: Do you have a proposal for where these symbols would be vended? My idea was to put them on Node or Element as statics, similar to the Symbol object design. The discussion on public-script-coord is this bug: In an alternate reality where modules were specced and implemented before symbols, they should go there. (Both for Symbol and for Node/Element; the placement of them on Symbol was a somewhat-last-minute hack when we realized modules were lagging symbols substantially.) But yes, in this reality somewhere in the Element/Node/HTMLElement hierarchy makes sense. (I'd guess Element?) We might not want to take it as precedent though. Or maybe we do, for consistency.
Re: Custom element lifecycle callbacks
On 1/9/15 9:33 AM, Anne van Kesteren wrote: On Fri, Jan 9, 2015 at 3:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: In any case, the fact that we're even _having_ this discussion and that it needs careful reading of the HTML spec is my point. It does seem however we could define this in a way that is safe. If by this you mean cloning of file inputs, then obviously yes. I never implied otherwise, as far as I can tell. If by this you mean a change from the current behavior to delayed cloning steps, without auditing all the cloning steps to make sure we don't end up in weird inconsistent states, then I don't think so. You really do have to carefully audit all the cloning steps in the spec, as well as any future cloning steps. -Boris
Re: Custom element lifecycle callbacks
On Thu, Jan 8, 2015 at 5:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/8/15 10:56 AM, Anne van Kesteren wrote: 2) For normal elements we act directly when they are cloned or adopted. How much interest is there in delaying what happens for normal elements to align them with custom elements? Which things are we talking about delaying? As much as possible. I'm pretty sure the prototype change that happens in Gecko on adopt right now is part of our security model and can't easily be delayed. I think we did actually discuss delaying this as part of how we wanted to solve this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 The idea was that for normal elements the callback would change the prototype, but for custom elements the custom element would have to write that implementation themselves. Thinking of this now however makes me think that such a solution would not exactly be ideal for a proper subclassing story (you would expect to inherit the callback behavior of normal elements). The other main thing that happens sync on clone is state propagation (e.g. copying of values for inputs, right)? There are some security considerations there too that would need to be considered for every bit of state that's propagated; consider: var input = document.createElement(input); input.value = file:///etc/passwd; var newInput = input.cloneNode(); newInput.type = file; I would like to see an actual list of the things we're considering delaying so we can think about the implications of doing that. Note that in the above example cloning callbacks would happen after the cloneNode() call but still before type is being set. So that might be okay? Custom elements have callbacks for these things (speculate ones marked with *): * created * attached * detached * attribute changed * adopted* * cloned* So far I've only been looking at the implications for aligning the last three. The first three seem a lot harder (and it's not entirely clear to me the created design even works that well, see the upgrading thread). -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 3:30 AM, Adam Klein ad...@chromium.org wrote: Do you have a proposal for where these symbols would be vended? In ES, builtin symbols are available as properties on the Symbol object, but clearly WebIDL shouldn't be adding things there. This might be a good question for public-script-coord. My idea was to put them on Node or Element as statics, similar to the Symbol object design. The discussion on public-script-coord is this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27553 -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 12:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: Ok, what about this testcase: var parent = document.createElement(x-my-element); var input = document.createElement(input); parent.appendChild(input); input.value = file:///etc/passwd; parent.cloneNode(true); and then in the cloning callback for x-my-element, assuming newNode is the clone: newNode.firstChild.type = file; That seems to me like it would do the type set before the cloning callback for the input runs, right? 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. It's a bit unclear to me why When an input element's type attribute changes state does not sanitize this value in any way though or how cloning it makes it a security concern. -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On 1/9/15 8:46 AM, Anne van Kesteren wrote: As far as I can tell from the specification, when the value IDL attribute is in the filename mode, any values that might be stored in internal slots are ignored. Hmm... That was not obvious to me, but OK. I guess it uses the list of selected files instead? And then the claim is that the only sanitization that's needed is step 2 of When an input element's type attribute changes state, to lose the old value, which was being stored all this time, when changing out of the file upload state? That's pretty bizarre, since it requires storing information that will never get used, but ok. As far as I can tell from the specification you cannot influence the value returned by input type=file.value in any way. UAs do not seem to be interoperable here. In particular, in some UAs cloning a file input copies the list of selected files, and in some it does not, with the spec seeming to side with the latter. It's a bit weird that cloning would normally copy the value, but not for file inputs. In any case, the fact that we're even _having_ this discussion and that it needs careful reading of the HTML spec is my point. -Boris
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 3:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: In any case, the fact that we're even _having_ this discussion and that it needs careful reading of the HTML spec is my point. It does seem however we could define this in a way that is safe. -- https://annevankesteren.nl/
Re: Custom element lifecycle callbacks
On Fri, Jan 9, 2015 at 2:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/15 7:14 AM, Anne van Kesteren wrote: OK. So just to be clear, the type will be set before the input's cloning callback runs, yes? 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 As far as I can tell from the specification, when the value IDL attribute is in the filename mode, any values that might be stored in internal slots are ignored. 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. As far as I can tell from the specification you cannot influence the value returned by input type=file.value in any way. -- https://annevankesteren.nl/
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
Re: Custom element lifecycle callbacks
On 1/9/15 4:28 AM, Anne van Kesteren wrote: On Thu, Jan 8, 2015 at 5:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: var input = document.createElement(input); input.value = file:///etc/passwd; var newInput = input.cloneNode(); newInput.type = file; Note that in the above example cloning callbacks would happen after the cloneNode() call but still before type is being set. So that might be okay? Ok, what about this testcase: var parent = document.createElement(x-my-element); var input = document.createElement(input); parent.appendChild(input); input.value = file:///etc/passwd; parent.cloneNode(true); and then in the cloning callback for x-my-element, assuming newNode is the clone: newNode.firstChild.type = file; That seems to me like it would do the type set before the cloning callback for the input runs, right? -Boris
Re: Custom element lifecycle callbacks
On Thu, Jan 8, 2015 at 7:56 AM, Anne van Kesteren ann...@annevk.nl wrote: 1) Can we use symbols to identify these instead? That gives us a guarantee they won't be used for other things and makes it somewhat safer to put them where they are located now. As Dimitri noted, I've expressed mild concerns about this in the past, but I may be coming around to the idea. The main advantage of using Symbols is that it would guarantee us the ability to add new callbacks in the future without fear of breaking existing elements, though I don't know how realistic a concern that is given the Callback suffix all these names have. Do you have a proposal for where these symbols would be vended? In ES, builtin symbols are available as properties on the Symbol object, but clearly WebIDL shouldn't be adding things there. This might be a good question for public-script-coord. - Adam
Re: Custom element lifecycle callbacks
On Thu, Jan 8, 2015 at 7:56 AM, Anne van Kesteren ann...@annevk.nl wrote: 1) Can we use symbols to identify these instead? That gives us a guarantee they won't be used for other things and makes it somewhat safer to put them where they are located now. cc'ing a few folks I heard expressing an opinion on this. 2) For normal elements we act directly when they are cloned or adopted. How much interest is there in delaying what happens for normal elements to align them with custom elements? I am interested in at least trying. I think Domenic is too. :DG
Re: Custom element lifecycle callbacks
On 1/8/15 10:56 AM, Anne van Kesteren wrote: 2) For normal elements we act directly when they are cloned or adopted. How much interest is there in delaying what happens for normal elements to align them with custom elements? Which things are we talking about delaying? I'm pretty sure the prototype change that happens in Gecko on adopt right now is part of our security model and can't easily be delayed. The other main thing that happens sync on clone is state propagation (e.g. copying of values for inputs, right)? There are some security considerations there too that would need to be considered for every bit of state that's propagated; consider: var input = document.createElement(input); input.value = file:///etc/passwd; var newInput = input.cloneNode(); newInput.type = file; I would like to see an actual list of the things we're considering delaying so we can think about the implications of doing that. -Boris
