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

[Ryosuke Niwa]

Hi all,

We have a nightmare of editing v.s. shadow DOM again.  The WebKit bug
66241<https://bugs.webkit.org/show_bug.cgi?id=66241>is currently the
top
renderer crasher in
Chromium<http://code.google.com/p/chromium/issues/detail?id=92757>(probably
affecting Safari 5.1 as much as well).

The problem is that when the shadow DOM is modified by the editing code, the
shadow host's style is marked dirty and updateLayout ends up
calling updateFromElement on the shadow host.
RenderTextControl*::updateFromElement then recreates the children of
innerTextElement, and invalidates all positions, ending selections, etc...
that editing code holds, causing the crash.

We can certainly add band aids in the editing code to check the nullity of
positions and node ref-pointers and exit early when they are null.  However,
this would result in wrong behavior because editing operations will end up
bailing out early in the middle of doing something.

It appears to me that there are a couple of approaches we can take but none
of them are promising:

   1. Avoid marking the shadow host dirty when editing code is modifying its
   shadow tree - This approach is a little fragile in that there's nothing that
   stops authors from writing selectors that matches shadow host with certain
   nodes in its shadow tree, in which case the problem persists.
   2. Avoid re-creating innerTextElement's contents when the shadow host's
   style changes - This requires a lot of work and may not be feasible in some
   cases because authors can override -webkit-apperance and there are certain
   properties such as whitespace, direction, etc... that need to propagate from
   the shadow host.
   3. Make editing code aware of this situation and update positions and
   node references as needed - As far as I can tell, this is infeasible.  It'll
   require us creating some XPath-like objects at every other line in editing,
   and computing node references and positions back from those objects.

Are there any clever alternatives here?

Best,
Ryosuke Niwa
Software Engineer
Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110828/5a225de0/attachment.html>