Re: XBL2: First Thoughts and Use Cases

On Tue, Dec 14, 2010 at 11:23 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/14/10 11:16 AM, Dimitri Glazkov wrote:
>>
>> This is interesting. Can you give an example? I am wondering if you
>> and Tab are talking about the same thing. What sorts of problems?
>
> The issues we've run into is that the shadow DOM tree can get mutated, which
> makes the actual DOM get out of sync with the data structures that represent
> insertion points (what I think XBL2 calls output ports) and the like).
>  After this, adding normal DOM children to the bound element at best puts
> them in the wrong place in the shadow DOM; at worst we've had exploitable
> crash issues we had to fix.

Hmm.  I'm not well-versed enough in XBL1 to understand what all the
difficulties are, but what we're envisioning is pretty simple and
shouldn't lead to many problems.

Given a template with some output ports, it's instantiated by cloning
the shadow DOM and then setting up a map of selectors->shadow-nodes to
represent the output ports.

If you mutate the shadow DOM without paying attention to the
outputPorts map, there are three possibilities for each port:

1. It points to a shadow node that wasn't mutated.  No change.

2. It points to a shadow node that was moved.  Everything currently
attached to that shadow node, and any new elements added to the
component which match the selector, will show up wherever the shadow
node was moved to.

3. It points to a shadow node that was removed.  Existing normal nodes
which were pointing to that shadow node now don't show up at all in
the final flattened tree (they lose their attachment, unless you ask
for them to be reattached).  New elements that get added and which
match the selector can either ignore the selector (because we know
that port is invalid) or just explicitly get put nowhere in the final
flattened tree.  Either option would be fine with me.


> Now if the shadow DOM can only be mutated by the binding itself, then it's
> possible to just avoid those problems in the binding script or restrict the
> things that script can do.  But if the shadow DOM is exposed to the page the
> bound element is in, then the implementation needs to handle arbitrary
> mutations _somehow_, since you can't rely on things outside the binding
> playing nice with the binding.  Or, of course, restrict what _that_ script
> can do with the shadow DOM, but that has more potential for weird breakage
> if the binding changes out from under the scripts that are trying to poke at
> it.

All of the cases I outlined above can be run into when you're mutating
a live template as well.  Are there additional cases I'm missing that
you have problems with?  Are they perhaps a result of having both a
mutable shadow and a live template?

~TJ

Received on Tuesday, 14 December 2010 19:41:29 UTC