DOMAttrModified mutation event is not supported by Safari 2.02 (416.13). Opera 7.2+ and Mozilla-based browsers support it. Steps to reproduce: 1- Load the provided URL 2- Hover the mouse over the Chinese flag Expected results: An alert box should report this text along with the related/correspondent event properties: "The attribute (evt.attrName) " + evt.attrName + " node of the " + evt.target.nodeName + " identified as " + evt.target.id + " has been modified. This alert proves that the current browser supports the " + evt.type + " mutation event. The type of change which triggered the DOMAttrModified event (evt.attrChange) is " + evt.attrChange + " and the name of the attribute (evt.attrName) is " + evt.attrName + ".\nThe previous value was \"" + evt.prevValue + "\"\nand its new value is \"" + evt.newValue + "\"\nThe relatedNode (evt.relatedNode) property value is " + evt.relatedNode + " and the relatedNode nodeName (evt.relatedNode.nodeName) is " + evt.relatedNode.nodeName which would output as "The attribute (evt.attrName) src node of the IMG identified as idMediumChina has been modified. This alert proves that the current browser supports the DOMAttrModified mutation event. The type of change which triggered the DOMAttrModified event (evt.attrChange) is 1 and the name of the attribute (evt.attrName) is src. The previous value was "http://www.gtalbot.org/GRAPHICS/PNG/MediumChinaFlagMouseOut.png" and its new value is "http://www.gtalbot.org/GRAPHICS/PNG/MediumChinaFlagMouseOver.png" The relatedNode (evt.relatedNode) property value is [object Attr] and the relatedNode nodeName (evt.relatedNode.nodeName) is src Another alert should popup for the switch back of the src of the image (since this is a rollover image). I searched for a duplicate and couldn't find any. Reference: http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-MutationEvent
Here is another mutation event example that doesn't work: http://www.carto.net/papers/svg/eventhandling/example4_mutationevent_properties_and_methods.svg This is implemented correctly in Opera 9 and Batik if you want to have a look for the correct values. Opera 9 normalizes the color values though, while it shouldn't in SVG 1.1. Batik does everything correctly. Thanks for having a look at this example as well when fixing this bug.
Please consider enabling the support for DOMAttrModified events as they are the only important missing DOM events. WebCore's Element.cpp contains a disabled implementation: void Element::dispatchAttrAdditionEvent(Attribute *attr) { ASSERT(!eventDispatchForbidden()); #if 0 if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER)) return; ExceptionCode ec = 0; dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, attr, attr->value(), attr->value(),document()->attrName(attr->id()), MutationEvent::ADDITION), ec); #endif } Why is this disabled? Are these events causing any problems?
I'd like to see this enabled as well. We are considering writable WAI-ARIA properties at the PFWG (W3C), which would require web app authors to respond to DOM property mutation. On FF, we are able to watch DOMAttrModified events. Like Frank, I too am curious, why is this code ifdef'ed out in WebKit? I'm guessing some performance concern?
Created attachment 22435 [details] Proposed fix for comments Here is a patch to enable them. Note, we do not have code for the MODIFICATION type. Only add/remove. Not really ready to land since there are no tests, etc. Someone should take this and run with it.
This missing event (along with DOMNodeInserted) is becoming ever more important as people will start using javascript implementations of XBL 2.0. When addressing dynamic changes to bound elements, these events are necessary to detect when changes / additions are made to bound elements and their custom attributes. This standard event is already supported in FF and Opera. It would be really nice if Webkit/Safari included it as well. Since there is a patch (previously submitted) attached, I added the EasyFix keyword. Further samples: http://www.quirksmode.org/dom/events/ (scroll for DOMAttrModified and see the test page). Thanks!!!!
Without support for MODIFICATION, WebKit will still fail the DOM mutation event test (#13) at http://www.w3.org/2008/06/mobile-test/
+1 to bump this bug's severity.
It would be tremendously useful to have the support for this event turned on, for all the reasons listed above.
+2 to bump this bug's severity.
Note you could keep performance by doing this via lazy instantiation. Only create and fire the events if there is a listener. Seems the best of both worlds.
*** Bug 23589 has been marked as a duplicate of this bug. ***
Simplified testcase: http://www.syncbyte.com/webkit/dom_modified_event.html Extracted test #13: http://www.w3.org/2008/06/mobile-test/
Please move this issue to high priority. It breaks many web apps. Whereas IE has onpropertychange, and Mozilla supports DOMAttrModified, what is Webkit (Safari & Chrome) alternative. For now I sway all my users from using Safari and Chrome!
<rdar://problem/7007800>
Created attachment 42551 [details] Patch with test case Work in progress. Based of an earlier patch by Timothy Hatcher. Passes <http://www.gtalbot.org/DHTMLSection/DOM2MutationEvents.html>. Passes the W3C DOM mutation test case at <http://www.w3.org/2008/06/mobile-test/> Passes <http://www.syncbyte.com/webkit/dom_modified_event.html> (thanks Rene Trost for the reduction). Included is a DRT/manual-test test case that checks that we conform to the W3C DOM Level 2 mutation event types spec. with respect to non-style DOM attributes. I'm heading off to bed now. I hope to finish up on the DRT/manual-test for the style attribute sometime tomorrow.
Created attachment 42552 [details] Self-contained Layout test For convenience, here is a self-contained version of the test case included in my patch. This test case checks only non-style DOM attribute addition, modification, and removal.
Do we really want to add support for this? There's general agreement on www-dom@w3.org that MutationEvents are something we want to move away from. Specifically, the use-cases that they do meet, they don't meet well and they are frought with problems. Mainly, they are inherently non-performant and invite crashiness. A relevant thread from www-dom: http://lists.w3.org/Archives/Public/www-dom/2009JanMar/0007.html An alternate proposal on public-webapps that addresses both the performance and crashiness issues: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0745.html There are some good use-cases for these types of events, but the current incarnation of MutationEvents is something noone seems happy with (not browser vendors or web developers).
I would like to add that mutation events are great if you use them properly. NWMatcher (a JavaScript CSS Selector engine) has no problems with them. View my fork here http://github.com/jdalton/nwmatcher/raw/master/src/nwmatcher.js. 1) Avoid compatibility issues through feature detection. 2) Avoid the `slow down` by removing the mutation event listener the first time it fires and set it up again on subsequent calls. 3) Detect if you are in an abusive while-loop and temporarily pause setting mutation events. With proper feature detection mutation events give NWMatcher a boost by allowing it to cache dom results under certain situations. Just because something is buggy doesn't mean it should be ripped-out/abandoned. Currently by viewing nwmatcher.js you will find it covers a lot of bugs in querySelectorAll(). This does not mean that continued support for querySelectorAll() should be dropped.
Created attachment 42614 [details] Patch with test cases Added code to test MODIFICATION firing from CSS property change to file "fire-DOMAttrModified-events.html". Added a new test file "fire-DOMAttrModified-MODIFICATION-when-handling-MODIFICATION-no-infinite-loop.html" to ensure that we do not go into an infinite loop when changing an attribute while servicing a MODIFICATION event (for example: http://www.syncbyte.com/webkit/dom_modified_event.html).
Created attachment 42615 [details] Patch with test cases Oops, accidentally left some code in the test cases that was used for debugging.
Created attachment 42616 [details] Self contained Layout test "fire-DOMAttrModified-events" For convenience, a self-contained version of the layout test "fire-DOMAttrModified-events.html" that is included in the patch.
Comment on attachment 42615 [details] Patch with test cases r- per comment 17. I suggest posting to webkit-dev for wider discussion of whether we want this.
This feature is necessary for webkit to be used with the next generation of web apps. More and more apps are needing precise control over DOM elements and the DOMAttrModified event is a critical part of that control.
I suggest posting to webkit-dev, explaining your precise use case. As we're currently don't intend to implement more DOM modification events, we need to know the use case in order to come up with a more robust solution that covers it.
Please note that the DOM Working Group intends to deprecate DOMAttrModified in DOM 3 due to lack of support and performance considerations. We have suggested a replacement, DOMAttrChangeRequest, as part of a "User Interface Independence" proposal sent to the WWW-DOM working group (and HTMLWG, PFWG, etc.) http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html Sent as an attachment to this email. http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0106.html
Lack of DOMAttrModified support introduces a security vulnerability in the Mutaprophylaxis JS library that protects nodes from unauthorized mutations by browser extensions and XSS.
*** Bug 76230 has been marked as a duplicate of this bug. ***
MutationObservers are the new hotness in this area. I don't think we want to implement DOMAttrModified.