On Wed, Aug 11, 2010 at 7:06 AM, Maciej Stachowiak <m...@apple.com> wrote:
> On Aug 9, 2010, at 8:21 PM, Timothy Hatcher wrote: > > Adding input/beforeinput events (#3) wont solve the need of most > extension developers that use mutation events today (the examples you cite). > So that makes it hard to remove them, especially over time, no matter how > much warning you give. > > Would it satisfy extension use cases if DOM mutation events got batched and > dispatched asynchronously as the generic DOMSubtreeModified?[1] Do > extensions need detailed change notification, or is a general "something > changed" notification good enough? > I can't think of any use-cases that couldn't reasonably be met with just a DOMSubtreeModified. There are two steps you're suggesting here, right? 1) Make mutation events async and 2) stop supporting mutation events other than DOMSubtreeModified. Is there any opposition to a patch that just makes the existing mutation events async? If not, we can try it and see if any sites break. My intuition is that very few sites or extensions actually depend on them being synchronous. That alone, I think would address the majority of mutation-event related crashing and does not prevent us from adding newer, better APIs. I think reducing mutation event support down to just DOMSubtreeModified, and > firing it only at the very end of operations that should be atomic, would > greatly reduce the risk of mutation-event-induced crashing, but would > probably still serve the key use cases. > Agreed. > For performance reasons, it would be even better to have a type of > notification that doesn't have to allocate an event object, as that is a > large part of the performance hit from mutation events. I gather that is > what the fancier new mutation events proposal does. > I think that's the key bit behind Jonas's proposal. Another thing to consider is attribute mutation events. We've been punting on implementing DOMAttrModified until this question is resolved ( https://bugs.webkit.org/show_bug.cgi?id=8191). Some options: 1. Bundle into the DOMSubtreeModified event 2. Ignore them as we do currently 3. Add the API in Jonas's proposal 4. Add a different API that lets you specify the attribute and/or subtree you care about, e.g. addAttributeChangedListener(callback, attribute, opt_ancestorNode) I would lean towards 4. It lets you listen to attribute changes without a significant performance penalty in most cases. Ojan
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
