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

Fri Jul 1 08:56:53 PDT 2011

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

Ryosuke Niwa <rniwa at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com,
                   |                            |mjs at apple.com,
                   |                            |ojan at chromium.org

--- Comment #6 from Ryosuke Niwa <rniwa at webkit.org>  2011-07-01 08:56:53 PST ---
(In reply to comment #5)
> 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.

One thing you can do is to attach DOMNodeRemoved event listener inside DONNodeInserted for each node.  That way, you'll know when a node is removed.

> 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.

What I'd like to do in the replacement for DOM mutation events is to send a list of DOM mutations such that you can construct undo and redo.  In fact, I've been working on a brand new design/spec for UndoMananger and Transaction that help address your use case that I'm planning to send out next week or so.

> 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.

See discussions on https://bugs.webkit.org/show_bug.cgi?id=55666

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