[webkit-dev] DOMAttrModified events in WebKit

[Maciej Stachowiak]

On Jan 5, 2010, at 4:50 PM, Chris Marrin wrote:

>
> There is a bug posted (https://bugs.webkit.org/show_bug.cgi?id=8191)  
> about the implementation of DOMAttrModified events. The  
> implementation is quite far along and there are many posts begging  
> for it, but it is stalled because of one comment (https://bugs.webkit.org/show_bug.cgi?id=8191#c17 
> ) which is opposed to it on the grounds that it would be slow and  
> buggy, and that there is an alternative proposal.
>
> I'm interested in this issue because of WebGL. There is currently an  
> implementation of a subset of X3D in WebGL (http://x3dom.org), which  
> allows you to add a 3D scene as a hierarchy of nodes rendered by  
> WebGL. They have an example of using mutation events to allow the  
> DOM to change the attributes of nodes in the hierarchy and have that  
> redraw the rendered scene. That's just one of the many uses of  
> mutation events. Others are sprinkled throughout the bug log.
>
> I don't think the discussion here should be whether or not mutation  
> events a A Good Thing or not. They are being put to good use in  
> Firefox already and they are part of DOM Level 2 already. The  
> question should be whether they would add value to WebKit without  
> penalizing performance when they are not used. I think there is  
> enough evidence to say that they would be useful for many purposes.  
> And from a cursory look at the patch it appears that, while there  
> would be overhead in doing the checks, it would be fairly minor  
> unless an event were actually attached to an attribute. And more  
> might be done to short circuit earlier and further reduce the  
> overhead. But I haven't actually tried the patch to see what the  
> baseline overhead is.
>
> If we reach consensus that we should add this feature, I would be  
> happy to get some numbers about the overhead.

I think DOM mutation events in general and DOMAttrModified in  
particular are not so great. It's pretty hard to implement mutation  
events not to hurt performance when they are not used, though  
possible. However, it's even harder to avoid even a single mutation  
event anywhere putting the whole DOM into slow mode. In addition,  
mutation events have poorly defined semantics which make it much more  
complex to ensure that DOM code is correct. They tend to be fired at  
awkward points, often in the middle of compound operations, and they  
are allowed to themselves make arbitrary DOM mutations. Coding  
defensively against this adds a lot of complexity, for the mutation  
events we already support. And it has been a major source of bugs,  
including security bugs.

If at all possible, I would prefer to help develop and promote a  
superior alternative to DOM events rather than extending our DOM event  
support.

That being said, this is not a strong line in the sand. If enough  
interesting content comes to depend on DOMAttrModified, then it may be  
worth implementing it notwithstanding the risks.

  - Maciej