Bug 8191 - DOMAttrModified mutation event support
Summary: DOMAttrModified mutation event support
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 416.x
Hardware: PC All
: P2 Normal
Assignee: Nobody
URL: http://www.gtalbot.org/DHTMLSection/D...
Keywords: InRadar
: 23589 76230 (view as bug list)
Depends on:
Blocks: 6590 20162 20517
  Show dependency treegraph
 
Reported: 2006-04-04 21:59 PDT by Gérard Talbot
Modified: 2014-05-20 03:14 PDT (History)
35 users (show)

See Also:


Attachments
Proposed fix for comments (2.05 KB, patch)
2008-07-22 15:51 PDT, Timothy Hatcher
no flags Details | Formatted Diff | Diff
Patch with test case (14.77 KB, patch)
2009-11-05 01:12 PST, Daniel Bates
no flags 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 Details | Formatted Diff | Diff
Patch with test cases (21.89 KB, patch)
2009-11-05 17:59 PST, Daniel Bates
ap: review-
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

Note You need to log in before you can comment on or make changes to this bug.
Description Gérard Talbot 2006-04-04 21:59:41 PDT
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
Comment 1 Andreas Neumann 2007-01-10 13:57:45 PST
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.
Comment 2 Frank Illenberger 2008-03-24 04:17:24 PDT
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?
Comment 3 David Bolter 2008-05-09 10:32:04 PDT
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 Timothy Hatcher 2008-07-22 15:51:45 PDT
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.
Comment 5 Brad 2008-08-26 08:10:02 PDT
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!!!!
Comment 6 David Harrison 2008-09-20 09:33:06 PDT
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 David Bolter 2008-09-22 06:49:57 PDT
+1 to bump this bug's severity.
Comment 8 Antoine Quint 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 Gérard Talbot 2009-01-22 23:35:16 PST
+2 to bump this bug's severity.
Comment 10 David Bolter 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 Anthony Ricaud 2009-01-29 02:53:15 PST
*** Bug 23589 has been marked as a duplicate of this bug. ***
Comment 12 Rene Trost 2009-02-17 20:24:33 PST
Simplified testcase:
http://www.syncbyte.com/webkit/dom_modified_event.html

Extracted test #13: http://www.w3.org/2008/06/mobile-test/
Comment 13 Newton Chan 2009-04-30 16:23:11 PDT
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 David Kilzer (:ddkilzer) 2009-06-25 13:31:09 PDT
<rdar://problem/7007800>
Comment 15 Daniel Bates 2009-11-05 01:12:25 PST
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.
Comment 16 Daniel Bates 2009-11-05 01:22:56 PST
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.
Comment 17 Ojan Vafai 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:
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).
Comment 18 John-David Dalton 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 Daniel Bates 2009-11-05 17:53:06 PST
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).
Comment 20 Daniel Bates 2009-11-05 17:59:27 PST
Created attachment 42615 [details]
Patch with test cases

Oops, accidentally left some code in the test cases that was used for debugging.
Comment 21 Daniel Bates 2009-11-05 18:31:27 PST
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 22 Alexey Proskuryakov 2009-11-05 19:33:43 PST
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.
Comment 23 Matt 2010-09-01 09:37:30 PDT
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 Alexey Proskuryakov 2010-09-01 09:45:58 PDT
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 James Craig 2010-09-02 14:33:18 PDT
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
Comment 26 Eli Grey (:sephr) 2010-10-17 16:09:39 PDT
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 Alexey Proskuryakov 2012-01-12 23:49:25 PST
*** Bug 76230 has been marked as a duplicate of this bug. ***
Comment 28 Adam Barth 2012-07-19 15:12:41 PDT
MutationObservers are the new hotness in this area.  I don't think we want to implement DOMAttrModified.