Bug 8191

Summary:

DOMAttrModified mutation event support

Product:

WebKit

Reporter:

Gérard Talbot (no longer involved) <browserbugs2>

Component:

DOM

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED WONTFIX

Severity:

Normal

CC:

abarth, a.neumann, ap, a.renevier, aroben, bdakin, bdginc, bugmail, clown, david.bolter, dbates, dieter, emacemac7, golod95, ian, illenberger, jcraig, jdv, jeff, john.david.dalton, kangax, lon, manyoso, ml, nicolas.paton, ojan, p.jacquemart, rafael.lobo, rob.moore, rwlbuis, shogun70, syoichi, the1geek, webdev, yonathan

Priority:

Keywords:

InRadar

Version:

416.x

Hardware:

OS:

All

URL:

http://www.gtalbot.org/DHTMLSection/DOM2MutationEvents.html

Bug Depends on:

Bug Blocks:

6590, 20162, 20517

Attachments:

Description	Flags
Proposed fix for comments	none
Patch with test case	none
Self-contained Layout test	none
Patch with test cases	none
Patch with test cases	ap: review-
Self contained Layout test "fire-DOMAttrModified-events"	none

Gérard Talbot (no longer involved)

Reported 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

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
Show Obsolete (4) View All Add attachment proposed patch, testcase, etc.

Andreas Neumann

Comment 1 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.

Frank Illenberger

Comment 2 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?

David Bolter

Comment 3 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?

Timothy Hatcher

Comment 4 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.

Brad

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

David Harrison

Comment 6 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/

David Bolter

Comment 7 2008-09-22 06:49:57 PDT

+1 to bump this bug's severity.

Antoine Quint

Comment 8 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.

Gérard Talbot (no longer involved)

Comment 9 2009-01-22 23:35:16 PST

+2 to bump this bug's severity.

David Bolter

Comment 10 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.

Anthony Ricaud

Comment 11 2009-01-29 02:53:15 PST

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

Rene Trost

Comment 12 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/

Newton Chan

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

David Kilzer (:ddkilzer)

Comment 14 2009-06-25 13:31:09 PDT

<rdar://problem/7007800>

Daniel Bates

Comment 15 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.

Daniel Bates

Comment 16 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.

Ojan Vafai

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

John-David Dalton

Comment 18 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.

Daniel Bates

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

Daniel Bates

Comment 20 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.

Daniel Bates

Comment 21 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.

Alexey Proskuryakov

Comment 22 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.

Matt

Comment 23 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.

Alexey Proskuryakov

Comment 24 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.

James Craig

Comment 25 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

Eli Grey (:sephr)

Comment 26 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.

Alexey Proskuryakov

Comment 27 2012-01-12 23:49:25 PST

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

Adam Barth

Comment 28 2012-07-19 15:12:41 PDT

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

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