55666 2011-03-03 06:22:44 -0800 DOMNodeRemoved events are not dispatched 2011-03-04 07:00:08 -0800 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) All All RESOLVED WONTFIX P2 Normal --- 0 aandrey webkit-unassigned aandrey ap darin jamesr mihaip mjs ojan rniwa oldest_to_newest 361557 0 aandrey 2011-03-03 06:22:44 -0800 DOMNodeRemoved events are not dispatched in some cases (I'd even say, it is rarely dispatched). Repro steps: - open the attached test case - click DEL or BACKSPACE to delete the selected text - expected log messages from the DOMNodeRemoved event handler, but nothing happens NOTE: This test works on Safari 5.0.3 (6533.19.4) on Mac, but not on the latest versions of Chrome. AFAIU, this may be a good point to look into: https://bugs.webkit.org/show_bug.cgi?id=46936 361560 1 84552 aandrey 2011-03-03 06:24:07 -0800 Created attachment 84552 Test on missing DOMNodeRemoved events 361571 2 aandrey 2011-03-03 06:31:30 -0800 Also, if you delete the line 8 in the test case, here is the output in Safari 5.0.3: Event DOMNodeRemoved: // line #8 Event DOMNodeInserted: Event DOMNodeRemoved: // line #9 Event DOMNodeInserted: Event DOMNodeRemoved: Event DOMNodeRemoved: Event DOMNodeInserted: // line #9 Event DOMNodeRemoved: And in the latest Chrome 11.0.686.1: Event DOMNodeInserted: // line #9 Event DOMNodeRemoved: // line #9 Event DOMNodeInserted: // line #9 Event DOMNodeRemoved: // line #9 Event DOMNodeInserted: // line #9 Event DOMNodeRemoved: // line #9 Event DOMNodeInserted: // line #9 362260 3 rniwa 2011-03-03 21:34:15 -0800 This isn't a bug but rather a conscious behavior change per http://trac.webkit.org/changeset/73690. After this changeset, WebKit fires DOMNodeRemoved AFTER the node has been removed, in which case, the event doesn't bubble to the node's ancestors because by the time we fire the event, the node had already removed from the document and therefore has no parent. You can listen to DOMSubtreeModified to detect node removal if you want to detect descendent nodes being removed. Please let me know if this alternative isn't adequate for your purpose and poses significant challenges. 362293 4 ojan 2011-03-03 22:48:05 -0800 Is there a page that breaks because of this? If not, I'm tempted to WONTFIX this given that subtreemodified still works and DOMNodeRemoved still works if you add the listener to the node itself. 362316 5 aandrey 2011-03-03 23:55:18 -0800 Strange, according to the http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeRemoved - "This event must be dispatched before the removal takes place." Is this a wrong place to look at, or we just don't care about the standards? :) I am more than happy to use a workaround using DOMSubtreeModified, but I failed to find one... Can you give me a good recipe how to use it, so that I should not miss DOMNodeRemoved events? If I remember correctly, I was not able to determine the particular DOM node that was removed from a subtree. Seems like there is no way now to catch the removed DOM node directly from the event?! 362320 6 ojan 2011-03-04 00:05:09 -0800 (In reply to comment #5) > Strange, according to the http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeRemoved - "This event must be dispatched before the removal takes place." Is this a wrong place to look at, or we just don't care about the standards? :) This in an intentional experiment to see if we can get away with diverging from the current specification without hurting web compatibility. If we succeed, then we will encourage other browser vendors to follow suite and will try to get the standard changed. > I am more than happy to use a workaround using DOMSubtreeModified, but I failed to find one... Can you give me a good recipe how to use it, so that I should not miss DOMNodeRemoved events? If I remember correctly, I was not able to determine the particular DOM node that was removed from a subtree. Seems like there is no way now to catch the removed DOM node directly from the event?! Correct. There's no way to get the list of nodes removed without keeping track of it yourself. Is there a web page that's not working? What are you trying to do that you need this information? At a high-level, mutation events cause a lot of problems for browser developers without really helping web developers much. In addition, they have performance costs that web developers are rightfully unaware of. So we're seeing how much we can get away with modifying them to avoid these problems. There are a number of proposals for full replacements of mutation events, but none of them are currently being worked on. 362321 7 rniwa 2011-03-04 00:17:29 -0800 (In reply to comment #5) > Strange, according to the http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeRemoved - "This event must be dispatched before the removal takes place." Is this a wrong place to look at, or we just don't care about the standards? :) This is a willful violation of the spec. Also note that DOM Level 3 deprecates the use of DOM mutation events entirely. > I am more than happy to use a workaround using DOMSubtreeModified, but I failed to find one... Can you give me a good recipe how to use it, so that I should not miss DOMNodeRemoved events? If I remember correctly, I was not able to determine the particular DOM node that was removed from a subtree. Seems like there is no way now to catch the removed DOM node directly from the event?! Ah, DOMSubtreeModified might not be a good alternative. Try attaching an event listener for DOMNodeRemoved to every child node. Then the event will fire for each node after the node has been removed. 362323 8 aandrey 2011-03-04 00:23:37 -0800 I see. I am working on the editor inside the Web Inspector: https://bugs.webkit.org/show_bug.cgi?id=53588 I already use the DOMSubtreeModified event to hack around the "missing" DOMNodeRemoved events, but in some corner cases it still does not work. I do not want to traverse the whole subtree every time a node is removed for obvious performance reasons. Also it may not be a good idea to listen for DOMNodeRemoved on every DOM node inside the subtree - it does not seem to be a robust solution, and, if I understand correctly, the parent node of the remove node will still be unavailable. In other words, a DOMNodeRemoved event dispatched BEFORE the removal takes place - is exactly what I need. And now I have to invent a workaround to "emulate" it :) 362328 9 rniwa 2011-03-04 00:29:31 -0800 (In reply to comment #8) > I already use the DOMSubtreeModified event to hack around the "missing" DOMNodeRemoved events, but in some corner cases it still does not work. I do not want to traverse the whole subtree every time a node is removed for obvious performance reasons. Why do you need to detect a node removal? >Also it may not be a good idea to listen for DOMNodeRemoved on every DOM node inside the subtree - it does not seem to be a robust solution, and, if I understand correctly, the parent node of the remove node will still be unavailable. Yes, the parent node won't available. > In other words, a DOMNodeRemoved event dispatched BEFORE the removal takes place - is exactly what I need. And now I have to invent a workaround to "emulate" it :) For what do you use DOMNodeRemoved? 362339 10 aandrey 2011-03-04 00:38:56 -0800 In the contentEditable editor I listen for the DOM mutation events to find out the DOM nodes that were modified, inserted or removed by the user, so that I could update the underlying text model being edited. For the "modified" part I use DOMCharacterDataModified event, and for the "inserted" - DOMNodeInserted, and both work perfectly. The problem now is how to track the removed DOM nodes... 362360 11 rniwa 2011-03-04 01:20:18 -0800 (In reply to comment #10) > In the contentEditable editor I listen for the DOM mutation events to find out the DOM nodes that were modified, inserted or removed by the user, so that I could update the underlying text model being edited. For the "modified" part I use DOMCharacterDataModified event, and for the "inserted" - DOMNodeInserted, and both work perfectly. The problem now is how to track the removed DOM nodes... You can listen to DOMNodeInserted, and then add an event listener for DOMNodeRemoved on that node inside the event listener and you can also remember the parent node. When the node is removed, DOMNodeRemoved is fired. 362366 12 rniwa 2011-03-04 01:31:52 -0800 I did some research on how IE9 handles this. It fires DOMNodeRemoved (possibly others) on all the nodes it intends to remove before making any mutations. It then mutates the DOM and fires the rest of mutation events asynchronously. Mimicking this behavior in WebKit poses a challenge because editing code assumes that mutations happen in place (i.e. when we invoke a function). One possible work-around is to simulate the entire editing command in some isolated world where we detect which node is removed, and then re-run the editing command on the actual DOM. It's like run the command, undo it, and then redo it again where only the last redo part is visible to scripts. 362372 13 aandrey 2011-03-04 01:46:47 -0800 Ryosuke, thanks for the research and your ideas! I will try to workaround this by adding DOMNodeRemoved listeners only on direct children of the subtree I need to monitor, and traverse those children on the DOMSubtreeModified events to find the removed nodes inside those subtrees. Such combined solution seems to be acceptable for me from the performance point of view. 362401 14 rniwa 2011-03-04 03:25:29 -0800 (In reply to comment #13) > I will try to workaround this by adding DOMNodeRemoved listeners only on direct children of the subtree I need to monitor, and traverse those children on the DOMSubtreeModified events to find the removed nodes inside those subtrees. Such combined solution seems to be acceptable for me from the performance point of view. Great! Let me know how it goes. I'm very much interested in knowing if new behavior makes something impossible or there is a reasonable work-around to it. 362473 15 aandrey 2011-03-04 07:00:08 -0800 I implemented the suggested workaround (details here: https://bugs.webkit.org/show_bug.cgi?id=55769), and it seems working fine. Marking this issue as WONTFIX. 84552 2011-03-03 06:24:07 -0800 2011-03-03 06:24:07 -0800 Test on missing DOMNodeRemoved events test.html text/html 2226 aandrey PGh0bWw+CjxoZWFkPgogICAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgICAgICAjbWFpbiB7 CiAgICAgICAgICAgIC13ZWJraXQtdXNlci1tb2RpZnk6IHJlYWQtd3JpdGUtcGxhaW50ZXh0LW9u bHk7CiAgICAgICAgfQogICAgICAgICNsb2dzIHsKICAgICAgICAgICAgd2hpdGUtc3BhY2U6IHBy ZTsKICAgICAgICB9CiAgICA8L3N0eWxlPgo8L2hlYWQ+CgoKPGJvZHk+CjxkaXYgaWQ9Im1haW4i PjwvZGl2Pgo8aW5wdXQgdHlwZT0iYnV0dG9uIiB2YWx1ZT0iQ2xlYXIiIG9uY2xpY2s9ImxvZ3Mu dGV4dENvbnRlbnQ9JyciIC8+CjxkaXYgaWQ9ImxvZ3MiPjwvZGl2PgoKPHNjcmlwdD4KICAgIHZh ciBtYWluID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoIm1haW4iKTsKICAgIHZhciBsb2dzID0g ZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoImxvZ3MiKTsKCiAgICB2YXIgbGluZXMgPSBbXTsKICAg IGZvciAodmFyIGkgPSAwOyBpIDwgMTA7ICsraSkgewogICAgICAgIGxpbmVzLnB1c2goJzxkaXY+ PHNwYW4gY2xhc3M9IndlYmtpdC1qYXZhc2NyaXB0LWNvbW1lbnQiPi8vIGxpbmUgIycgKyAoaSsx KSArICc8L3NwYW4+PC9kaXY+Jyk7CiAgICB9CiAgICBtYWluLmlubmVySFRNTCA9IGxpbmVzLmpv aW4oJycpOwoKICAgIGZ1bmN0aW9uIGhhbmRsZUV2ZW50KGUpIHsKICAgICAgICBsb2dzLnRleHRD b250ZW50ICs9ICJFdmVudCAiICsgZS50eXBlICsgIjogIiArIGUudGFyZ2V0LnRleHRDb250ZW50 ICsgIlxuIjsKICAgIH0KCiAgICBtYWluLmFkZEV2ZW50TGlzdGVuZXIoIkRPTUNoYXJhY3RlckRh dGFNb2RpZmllZCIsIGhhbmRsZUV2ZW50LCBmYWxzZSk7CiAgICBtYWluLmFkZEV2ZW50TGlzdGVu ZXIoIkRPTU5vZGVJbnNlcnRlZCIsIGhhbmRsZUV2ZW50LCBmYWxzZSk7CiAgICBtYWluLmFkZEV2 ZW50TGlzdGVuZXIoIkRPTU5vZGVSZW1vdmVkIiwgaGFuZGxlRXZlbnQsIGZhbHNlKTsKCiAgICBm dW5jdGlvbiBzaW11bGF0ZUtleXByZXNzKGVsbSkgewogICAgICAgIHZhciBlID0gZG9jdW1lbnQu Y3JlYXRlRXZlbnQoIktleWJvYXJkRXZlbnQiKTsKICAgICAgICBlLmluaXRLZXlib2FyZEV2ZW50 KAogICAgICAgICAgICAgICAgImtleXByZXNzIiwgICAgICAgLy8gIGluIERPTVN0cmluZyB0eXBl QXJnLAogICAgICAgICAgICAgICAgdHJ1ZSwgICAgICAgICAgICAgLy8gIGluIGJvb2xlYW4gY2Fu QnViYmxlQXJnLAogICAgICAgICAgICAgICAgdHJ1ZSwgICAgICAgICAgICAgLy8gIGluIGJvb2xl YW4gY2FuY2VsYWJsZUFyZywKICAgICAgICAgICAgICAgIG51bGwsICAgICAgICAgICAvLyAgaW4g dmlld3M6OkFic3RyYWN0VmlldyB2aWV3QXJnLAogICAgICAgICAgICAgICAgIlUrMDAzMCIsCiAg ICAgICAgICAgICAgICAvLyJVKzAwN0YiLCAgICAgICAgICAvLyBpbiBET01TdHJpbmcga2V5SWRl bnRpZmllckFyZywKICAgICAgICAgICAgICAgIDAsIC8vIGluIHVuc2lnbmVkIGxvbmcga2V5TG9j YXRpb25BcmcsCiAgICAgICAgICAgICAgICAiIiAvL2luIERPTVN0cmluZyBtb2RpZmllcnNMaXN0 CiAgICAgICAgKTsKICAgICAgICBlbG0uZGlzcGF0Y2hFdmVudChlKTsKICAgIH0KCiAgICBmdW5j dGlvbiBzZWxlY3RUZXh0QW5kRGVsZXRlKCkgewogICAgICAgIHZhciBzZWxlY3Rpb24gPSB3aW5k b3cuZ2V0U2VsZWN0aW9uKCk7CiAgICAgICAgc2VsZWN0aW9uLnJlbW92ZUFsbFJhbmdlcygpOwoK ICAgICAgICB2YXIgc3RhcnROb2RlID0gbWFpbi5maXJzdENoaWxkLm5leHRFbGVtZW50U2libGlu Zy5uZXh0RWxlbWVudFNpYmxpbmc7CiAgICAgICAgdmFyIGVuZE5vZGUgPSBtYWluLmxhc3RDaGls ZC5wcmV2aW91c0VsZW1lbnRTaWJsaW5nLnByZXZpb3VzRWxlbWVudFNpYmxpbmc7CgogICAgICAg IHZhciByYW5nZSA9IGRvY3VtZW50LmNyZWF0ZVJhbmdlKCk7CiAgICAgICAgcmFuZ2Uuc2V0U3Rh cnQoc3RhcnROb2RlLmZpcnN0Q2hpbGQuZmlyc3RDaGlsZCwgc3RhcnROb2RlLnRleHRDb250ZW50 Lmxlbmd0aCk7CiAgICAgICAgcmFuZ2Uuc2V0RW5kKGVuZE5vZGUuZmlyc3RDaGlsZC5maXJzdENo aWxkLCBlbmROb2RlLnRleHRDb250ZW50Lmxlbmd0aCk7CiAgICAgICAgc2VsZWN0aW9uLmFkZFJh bmdlKHJhbmdlKTsKCi8vICAgICAgICBzaW11bGF0ZUtleXByZXNzKGxvZ3MpOwogICAgfQoKICAg IHNlbGVjdFRleHRBbmREZWxldGUoKTsKCjwvc2NyaXB0PgoKPC9ib2R5Pgo8L2h0bWw+CiAgICAg ICAg