Bug 8191 – DOMAttrModified mutation event support

• Component: DOM
• Status: RESOLVED WONTFIX

[Gérard Talbot (no longer involved)]

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

[Andreas Neumann]

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.

[Frank Illenberger]

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?

[David Bolter]

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?

[Timothy Hatcher]

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.

[Brad]

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

[David Harrison]

Without support for MODIFICATION, WebKit will still fail the DOM mutation event test (#13) at http://www.w3.org/2008/06/mobile-test/

[David Bolter]

+1 to bump this bug's severity.

[Antoine Quint]

It would be tremendously useful to have the support for this event turned on, for all the reasons listed above.

[Gérard Talbot (no longer involved)]

+2 to bump this bug's severity.

[David Bolter]

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.

[Anthony Ricaud]

*** Bug 23589 has been marked as a duplicate of this bug. ***

[Rene Trost]

Simplified testcase:
http://www.syncbyte.com/webkit/dom_modified_event.html

Extracted test #13: http://www.w3.org/2008/06/mobile-test/

[Newton Chan]

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!

 

[David Kilzer (:ddkilzer)]

<rdar://problem/7007800>

[Daniel Bates]

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.

[Daniel Bates]

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.

[Ojan Vafai]

Do we really want to add support for this? There's general agreement on [e-mail] 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).

[John-David Dalton]

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.

[Daniel Bates]

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

[Daniel Bates]

Created attachment 42615 [details]
Patch with test cases

Oops, accidentally left some code in the test cases that was used for debugging.

[Daniel Bates]

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.

[Alexey Proskuryakov]

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.

[Matt]

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.

[Alexey Proskuryakov]

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.

[James Craig]

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

[Eli Grey (:sephr)]

Lack of DOMAttrModified support introduces a security vulnerability in the Mutaprophylaxis JS library that protects nodes from unauthorized mutations by browser extensions and XSS.

[Alexey Proskuryakov]

*** Bug 76230 has been marked as a duplicate of this bug. ***

[Adam Barth]

MutationObservers are the new hotness in this area.  I don't think we want to implement DOMAttrModified.