[webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

[James Robinson]

On Mon, Aug 9, 2010 at 4:39 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth <abarth at webkit.org> wrote:
>
>> On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> > If mutation events tend to break editing, one simple solution is to turn
>> then off within the scope of editing operations and send a single mutation
>> event at the end. It's not clear if that kind of solution would be
>> appropriate to expose to Web content, though; you can't do the RAII idiom in
>> JavaScript so there could be too much risk of staying stuck in the "mutation
>> events deferred" state. On the other hand, a dynamic-wind-style solution
>> might be appropriate. This is one tiny example of how the same abstractions
>> might not be right internally and externally.
>>
>> If we don't already have it, we definitely want a RAII for turning off
>> mutation events (or at least ASSERTing that we're not trying to fire
>> them) for the parser.  The new and old tree builders might explode if
>> they ever fire a mutation event.
>
>
> I'm trying to figure out what we should do with DOM Mutation Events. The
> general agreement from the www-dom discussion of mutation events was that
> they are the wrong abstraction for editing related code. beforeinput/input
> events meet editing needs better. So, that leaves a small list of relatively
> low-priority use-cases. See
> http://www.w3.org/2008/webapps/wiki/MutationReplacement for some of them.
>
> Mutation events are a huge source of crashes and they complicate WebCore
> code considerably. Also, I don't see any evidence that mutation events are
> used much other than as a blunt dirty bit for editing code, which can now be
> replaced with the input event. Here's some options I see:
>
>    1. Make the existing mutation events them async. That would address all
>    the issues with them except for the performance cost and would only be
>    backwards-incompatible for the small percentage of sites that depend on the
>    events firing synchronously.
>    2. Drop support for them with no replacement.
>    3. Complete the implementation of beforeinput/input events to support
>    editing use-cases then do 1 or 2.
>    4. Same as above, but also implement a low-level replacement for
>    mutation events (e.g. something like
>    http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html).
>
> Do any of these options sound feasible or is the only option to do the very
> large amount of work to make existing mutation events work?
>

An additional data point is that the DOM events level 3 specification
declares mutation events to be deprecated and includes the following text:

"Many single modifications of the tree can cause multiple mutation events to
be dispatched. Rather than attempt to specify the ordering of mutation
events due to every possible modification of the tree, the ordering of these
events is left to the implementation."

This means that the mutation event behavior for anything but the absolute
simplest of cases is implementation-defined, and in practice different
across browsers and browser versions.  Additionally, the DOM events spec
currently has no editor and so there's not a great chance of improvements in
the spec in the short term.

I'd strongly suggest that we go with option 2.  Problems with editing and
input should be fixed by editing and input APIs and there honestly are not
many other compelling use cases that actually work today.  Mutation events
have caused a lot of nasty crashes and complexity in WebKit and there's no
reason to believe that this will improve in the short term.

- James



> Ojan
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100809/160e66c4/attachment.html>