[Webkit-unassigned] [Bug 63621] REGRESSION: DOMNodeRemoved doesn't fire when removing text node in contenteditable

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=63621





--- Comment #5 from Erik Hesselink <hesselink at gmail.com>  2011-07-01 06:57:06 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> >   * It is hard to use. Monitoring a section of HTML (say, a contenteditable area) can now only be done by attaching event listeners to every node, which is a kind of web development antipattern.
> 
> On WebKit, you can use input event to monitor a contenteditable area. It's fired every time DOM is about to modify in the element.
> 
> Ultimately, we'd like to get rid of mutation events. See "Mutation events replacement" on public-webapps.

I'll give a little bit of background about what we are using DOM mutation events for. We are developing a web application which includes an html editor based on contenteditable. In this contenteditable we have user actions like typing, calls to execCommand and custom actions that modify the DOM directly.

We use DOM mutation events to basically keep a shadow DOM, which we use to have 'live' computations on the DOM that automatically update on DOM changes in a performant way (i.e. without rescanning the entire document). This keeps our UI state correct, among other things.

We also have an automatic undo stack based on DOM mutation events. Each action on the DOM is wrapped in markers, and between these markers we track the events. We can then undo the individual events to undo the full action.

For both these applications (we have a few more, but these are the largest) we need the information and guarantees DOM mutation events give us. The 'input' event doesn't give nearly enough information. The new spec probably also doesn't (I'll send an email to public-webapps soon), and also isn't available yet.

My worry is that these changes, which make it easier for you to fix bugs, keep breaking our application in unexpected ways. Do you have any high level overview of what you are planning to change, and when? This would really help us in ensuring our application will keep working on Safari and Chrome.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.