[webkit-dev] Top Crasher: Shadow DOM and Editing Collide Again

[Ryosuke Niwa]

Thanks for the analysis, Dimitri.

On Mon, Aug 29, 2011 at 12:01 PM, Dimitri Glazkov <dglazkov at chromium.org>wrote:

> 1 -- the style is calculated in the middle of the editing command run,
> producing definitely incorrect results (for example, in the repro in
> bug, you will have style calculated for a string "aa" in the text
> area, since we first insert data, and then remove data.


This isn't really unwanted.  It happens everywhere in editing and we need
those style recalculation in place because editing code inherently relies on
renderStyle.  i.e. updating styles at intermediate states are needed by
editing code.

2 -- the style recalc my trigger forms machinery to assume that this
> change is "for realz" and start updating its form values, and, as it
> happens in the repro on bug, stomp over the CharacterData we just
> started to update, leading to BOOM.
>

This is the problem.  It's same thing as if mutation event listeners started
modifying DOM in the middle of an editing command.

 A. Ensure that any layout that's forced by an editing operation is
> performed in a specific order, ensuring that the forced style recalc
> does not find the tree in a mid-transition state.


I don't think this approach is feasible given that it requires us modifying
hundreds of lines of editing code.

B. Change editing commands to force layout only at the end of the
> operation, making the commands more atomic.
>

I can safely say this is impossible because editability itself depends on
style; i.e. whether a node is editable or not is determined by -the value
webkit-user-modify.  Nodes without renderers are treated differently than
nodes with renderers in editing code.

C. Add case-specific hacks to areas of code where we know there are
> troubles. For example, we could add a flag to HTMLTextAreaElement to
> say "please ignore, this is not a real style recalc, the real one is
> coming up".
>

As far as I'm concerned, this is the only practical solution among the
three.

I'm still quite skeptical as to why we'd have to re-create descendent nodes
of innerTextElement upon style recalc / layout.  It seems odd that the life
time of the shadow DOM is tied to its host's style change.

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110829/fccb54a8/attachment.html>