63621 2011-06-29 05:28:39 -0700 REGRESSION: DOMNodeRemoved doesn't fire when removing text node in contenteditable 2012-06-03 00:22:41 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) Mac (Intel) OS X 10.6 RESOLVED WONTFIX Regression P1 Normal --- 1 hesselink webkit-unassigned ap darin mjs ojan rniwa oldest_to_newest 429535 0 99076 hesselink 2011-06-29 05:28:39 -0700 Created attachment 99076 Testcase showing the bug In the attached test case: * Select the text 'foo' by double clicking. * Press delete. In the console you can now see that the text node containing 'foo' has been removed, but no DOMNodeRemoved event has been fired (only DOMCharacterDataModified). 429705 1 ap 2011-06-29 10:23:48 -0700 I can reproduce with ToT, but not with Safari/WebKit 5.0.5. 429709 2 rniwa 2011-06-29 10:31:11 -0700 This is a behavioral change since http://trac.webkit.org/changeset/73690, and it's intentional. The DOMNodeRemoved is fired for the node AFTER the node is removed from the document. However, because the node does not have a parent after the removal, it appears as if the event was never fired if you just attach an event handler on some ancestor. 430301 3 hesselink 2011-06-30 03:06:12 -0700 (In reply to comment #2) > This is a behavioral change since http://trac.webkit.org/changeset/73690, and it's intentional. The DOMNodeRemoved is fired for the node AFTER the node is removed from the document. However, because the node does not have a parent after the removal, it appears as if the event was never fired if you just attach an event handler on some ancestor. I don't really understand what that changeset does exactly (an explanation would be appreciated), but the current behavior is undesirable for several reasons: * It violates the specification. Even though it is deprecated, this is the specification that has been implemented, and such small deviations are confusing and a recipe for bugs. * It is inconsistent. Most DOMNodeRemoved events still fire before removal. * 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. 430417 4 rniwa 2011-06-30 08:05:13 -0700 (In reply to comment #3) > * It violates the specification. Even though it is deprecated, this is the specification that has been implemented, and such small deviations are confusing and a recipe for bugs. This is a willful violation of the spec. We've had many crashes and security vulnerabilities due to mutation events. > * It is inconsistent. Most DOMNodeRemoved events still fire before removal. Right. We'll eventually do that to doo DOMNodeRemoved. For example, adoptNode does the same. > * 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. 431131 5 hesselink 2011-07-01 06:57:06 -0700 (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. 431189 6 rniwa 2011-07-01 08:56:53 -0700 (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 640155 7 rniwa 2012-06-03 00:22:41 -0700 Given that we've added mutation observers API, I don't think we'll ever fix this bug. 99076 2011-06-29 05:28:39 -0700 2011-06-29 05:28:39 -0700 Testcase showing the bug ce.html text/html 1061 hesselink PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICA8dGl0bGU+RE9NTm9kZVJlbW92ZWQgZG9l c24ndCBmaXJlIG9uIHRleHQgbm9kZS48L3RpdGxlPgo8c3R5bGU+CiNjZQp7CiAgYm9yZGVyOiAx cHggc29saWQgYmxhY2s7CiAgcGFkZGluZzogNXB4Owp9Cjwvc3R5bGU+CjwvaGVhZD4KPGJvZHk+ CiAgPGRpdiBpZD0iY2UiIGNvbnRlbnRlZGl0YWJsZT0idHJ1ZSI+CiAgICA8dWw+CiAgICAgIDxs aT5Eb3VibGUgY2xpY2sgJ2ZvbycgYmVsb3cgdG8gc2VsZWN0IGl0LgogICAgICA8bGk+UHJlc3Mg ZGVsZXRlLgogICAgICA8bGk+T25seSBET01DaGFyYWN0ZXJEYXRhTW9kaWZpZWQgaXMgZmlyZWQs IG5vdCBET01Ob2RlUmVtb3ZlZCwKICAgICAgYnV0IHRoZSB0ZXh0IG5vZGUgaGFzIGJlZW4gcmVt b3ZlZCAoc2VlIGNvbnNvbGUpLgogICAgPC91bD4KICAgIDxwIGlkPSJwIj5mb288YnI+PC9wPgog IDwvZGl2Pgo8L2JvZHk+CjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4KCmZ1bmN0aW9u IGhhbmRsZXIgKGV2dCkKewogIGNvbnNvbGUubG9nKCJFdmVudDoiLCBldnQudHlwZSwgZXZ0LnRh cmdldCwgZXZ0KTsKICAvLyBUaW1lb3V0IGJlY2F1c2UgRE9NTm9kZVJlbW92ZWQgZmlyZXMgYmVm b3JlIHRoZSBhY3Rpb24gaGFwcGVucy4KICBzZXRUaW1lb3V0KGZ1bmN0aW9uICgpIHsgY29uc29s ZS5sb2coImNoaWxkTm9kZXMgb2YgUDoiLCBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgicCIpLmNo aWxkTm9kZXMpIH0sIDApOwp9CgpmdW5jdGlvbiBpbml0ICgpCnsKICBjb25zb2xlLmxvZygiY2hp bGROb2RlcyBvZiBQOiIsIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJwIikuY2hpbGROb2Rlcyk7 CiAgdmFyIGNlID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoImNlIik7CiAgY2UuYWRkRXZlbnRM aXN0ZW5lcigiRE9NTm9kZVJlbW92ZWQiLCAgICAgICAgICAgaGFuZGxlciwgZmFsc2UpOwogIGNl LmFkZEV2ZW50TGlzdGVuZXIoIkRPTUNoYXJhY3RlckRhdGFNb2RpZmllZCIsIGhhbmRsZXIsIGZh bHNlKTsKfQoKaW5pdCgpOwo8L3NjcmlwdD4KPC9odG1sPgo=