Bug 8191 - DOMAttrModified mutation event support
: DOMAttrModified mutation event support
: WebKit
: 416.x
: PC All
: P2 Normal
Assigned To:
: http://www.gtalbot.org/DHTMLSection/D...
: InRadar
: 6590 20162 20517
  Show dependency treegraph
Reported: 2006-04-04 21:59 PST by
Modified: 2012-07-19 15:12 PST (History)

Proposed fix for comments (2.05 KB, patch)
2008-07-22 15:51 PST, Timothy Hatcher
no flags Review Patch | Details | Formatted Diff | Diff
Patch with test case (14.77 KB, patch)
2009-11-05 01:12 PST, Daniel Bates
no flags Review Patch | Details | Formatted Diff | Diff
Self-contained Layout test (12.10 KB, text/html)
2009-11-05 01:22 PST, Daniel Bates
no flags Details
Patch with test cases (22.44 KB, patch)
2009-11-05 17:53 PST, Daniel Bates
no flags Review Patch | Details | Formatted Diff | Diff
Patch with test cases (21.89 KB, patch)
2009-11-05 17:59 PST, Daniel Bates
ap: review-
Review Patch | Details | Formatted Diff | Diff
Self contained Layout test "fire-DOMAttrModified-events" (14.08 KB, text/html)
2009-11-05 18:31 PST, Daniel Bates
no flags Details


You need to log in before you can comment on or make changes to this bug.

Description From 2006-04-04 21:59:41 PST
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.

------- Comment #1 From 2007-01-10 13:57:45 PST -------
Here is another mutation event example that doesn't work:

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.
------- Comment #2 From 2008-03-24 04:17:24 PST -------
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)
#if 0
    if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER))
    ExceptionCode ec = 0;
    dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, attr, attr->value(),
        attr->value(),document()->attrName(attr->id()), MutationEvent::ADDITION), ec);

Why is this disabled? Are these events causing any problems?
------- Comment #3 From 2008-05-09 10:32:04 PST -------
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?
------- Comment #4 From 2008-07-22 15:51:45 PST -------
Created an attachment (id=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.
------- Comment #5 From 2008-08-26 08:10:02 PST -------
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).
------- Comment #6 From 2008-09-20 09:33:06 PST -------
Without support for MODIFICATION, WebKit will still fail the DOM mutation event test (#13) at http://www.w3.org/2008/06/mobile-test/
------- Comment #7 From 2008-09-22 06:49:57 PST -------
+1 to bump this bug's severity.
------- Comment #8 From 2009-01-22 22:56:16 PST -------
It would be tremendously useful to have the support for this event turned on, for all the reasons listed above.
------- Comment #9 From 2009-01-22 23:35:16 PST -------
+2 to bump this bug's severity.
------- Comment #10 From 2009-01-23 05:26:25 PST -------
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.
------- Comment #11 From 2009-01-29 02:53:15 PST -------
*** Bug 23589 has been marked as a duplicate of this bug. ***
------- Comment #12 From 2009-02-17 20:24:33 PST -------
Simplified testcase:

Extracted test #13: http://www.w3.org/2008/06/mobile-test/
------- Comment #13 From 2009-04-30 16:23:11 PST -------
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!

------- Comment #14 From 2009-06-25 13:31:09 PST -------
------- Comment #15 From 2009-11-05 01:12:25 PST -------
Created an attachment (id=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.
------- Comment #16 From 2009-11-05 01:22:56 PST -------
Created an attachment (id=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.
------- Comment #17 From 2009-11-05 11:22:53 PST -------
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:

An alternate proposal on public-webapps that addresses both the performance and crashiness issues:

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).
------- Comment #18 From 2009-11-05 12:05:52 PST -------
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.
------- Comment #19 From 2009-11-05 17:53:06 PST -------
Created an attachment (id=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).
------- Comment #20 From 2009-11-05 17:59:27 PST -------
Created an attachment (id=42615) [details]
Patch with test cases

Oops, accidentally left some code in the test cases that was used for debugging.
------- Comment #21 From 2009-11-05 18:31:27 PST -------
Created an attachment (id=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 #22 From 2009-11-05 19:33:43 PST -------
(From update of attachment 42615 [details])
r- per comment 17.

I suggest posting to webkit-dev for wider discussion of whether we want this.
------- Comment #23 From 2010-09-01 09:37:30 PST -------
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.
------- Comment #24 From 2010-09-01 09:45:58 PST -------
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.
------- Comment #25 From 2010-09-02 14:33:18 PST -------
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.)

Sent as an attachment to this email.
------- Comment #26 From 2010-10-17 16:09:39 PST -------
Lack of DOMAttrModified support introduces a security vulnerability in the Mutaprophylaxis JS library that protects nodes from unauthorized mutations by browser extensions and XSS.
------- Comment #27 From 2012-01-12 23:49:25 PST -------
*** Bug 76230 has been marked as a duplicate of this bug. ***
------- Comment #28 From 2012-07-19 15:12:41 PST -------
MutationObservers are the new hotness in this area.  I don't think we want to implement DOMAttrModified.