DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth <abarth@webkit.org> wrote:
On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak <mjs@apple.com> wrote:
If mutation events tend to break editing, one simple solution is to turn then off within the scope of editing operations and send a single mutation event at the end. It's not clear if that kind of solution would be appropriate to expose to Web content, though; you can't do the RAII idiom in JavaScript so there could be too much risk of staying stuck in the "mutation events deferred" state. On the other hand, a dynamic-wind-style solution might be appropriate. This is one tiny example of how the same abstractions might not be right internally and externally.
If we don't already have it, we definitely want a RAII for turning off mutation events (or at least ASSERTing that we're not trying to fire them) for the parser. The new and old tree builders might explode if they ever fire a mutation event.
I'm trying to figure out what we should do with DOM Mutation Events. The general agreement from the www-dom discussion of mutation events was that they are the wrong abstraction for editing related code. beforeinput/input events meet editing needs better. So, that leaves a small list of relatively low-priority use-cases. See http://www.w3.org/2008/webapps/wiki/MutationReplacement for some of them. Mutation events are a huge source of crashes and they complicate WebCore code considerably. Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event. Here's some options I see: 1. Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. 2. Drop support for them with no replacement. 3. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. 4. Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html). Do any of these options sound feasible or is the only option to do the very large amount of work to make existing mutation events work? Ojan
On Mon, Aug 9, 2010 at 4:39 PM, Ojan Vafai <ojan@chromium.org> wrote:
On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth <abarth@webkit.org> wrote:
On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak <mjs@apple.com> wrote:
If mutation events tend to break editing, one simple solution is to turn then off within the scope of editing operations and send a single mutation event at the end. It's not clear if that kind of solution would be appropriate to expose to Web content, though; you can't do the RAII idiom in JavaScript so there could be too much risk of staying stuck in the "mutation events deferred" state. On the other hand, a dynamic-wind-style solution might be appropriate. This is one tiny example of how the same abstractions might not be right internally and externally.
If we don't already have it, we definitely want a RAII for turning off mutation events (or at least ASSERTing that we're not trying to fire them) for the parser. The new and old tree builders might explode if they ever fire a mutation event.
I'm trying to figure out what we should do with DOM Mutation Events. The general agreement from the www-dom discussion of mutation events was that they are the wrong abstraction for editing related code. beforeinput/input events meet editing needs better. So, that leaves a small list of relatively low-priority use-cases. See http://www.w3.org/2008/webapps/wiki/MutationReplacement for some of them.
Mutation events are a huge source of crashes and they complicate WebCore code considerably. Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event. Here's some options I see:
1. Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. 2. Drop support for them with no replacement. 3. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. 4. Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html).
Do any of these options sound feasible or is the only option to do the very large amount of work to make existing mutation events work?
An additional data point is that the DOM events level 3 specification declares mutation events to be deprecated and includes the following text: "Many single modifications of the tree can cause multiple mutation events to be dispatched. Rather than attempt to specify the ordering of mutation events due to every possible modification of the tree, the ordering of these events is left to the implementation." This means that the mutation event behavior for anything but the absolute simplest of cases is implementation-defined, and in practice different across browsers and browser versions. Additionally, the DOM events spec currently has no editor and so there's not a great chance of improvements in the spec in the short term. I'd strongly suggest that we go with option 2. Problems with editing and input should be fixed by editing and input APIs and there honestly are not many other compelling use cases that actually work today. Mutation events have caused a lot of nasty crashes and complexity in WebKit and there's no reason to believe that this will improve in the short term. - James
Ojan
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi Ojan.
Mutation events are a huge source of crashes and they complicate WebCore code considerably.
Indeed. I also think mutation events unnecessarily complicate the API space from a web content author's perspective.
Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event.
I think this is the key question -- how does existing content use mutation events, and what would we risk by changing or eliminating them? Another important question is whether/how important DOM API compatibility tests, like the Acid tests, use mutation events. What's the best way to answer these questions? I think that answer will probably guide our perspective on the options you listed.
Here's some options I see: Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. This seems like the most appealing option if (a) backwards compatibility requires us to keep mutation events, but (b) making them asynchronous doesn't harm that backwards compatibility in significant ways. Drop support for them with no replacement. This seems like the most appealing option if mutation events just aren't used. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. This seems like the most appealing option if we're going to try to coordinate our action on mutation events with third party changes. (Otherwise, the beforeinput/input events can be an independent concern.) Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html). I just skimmed this API description, but my take on it is that it's very similar to #1 -- it's still a pretty intrusive set of mutation-related APIs, just an asynchronous one. I'm not convinced by Jonas Sicking's claim that this API is significantly different because it lacks a bubble / capture phase. I don't think that was ever the main problem with mutation events.
So, I prefer #1 to #4, since #4 just seems like a more complicated way to avoid the burden of synchronous mutation events. Geoff
I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway. However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.). So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not. With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.). :DG< On Mon, Aug 9, 2010 at 5:11 PM, Geoffrey Garen <ggaren@apple.com> wrote:
Hi Ojan.
Mutation events are a huge source of crashes and they complicate WebCore code considerably.
Indeed. I also think mutation events unnecessarily complicate the API space from a web content author's perspective.
Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event.
I think this is the key question -- how does existing content use mutation events, and what would we risk by changing or eliminating them? Another important question is whether/how important DOM API compatibility tests, like the Acid tests, use mutation events. What's the best way to answer these questions? I think that answer will probably guide our perspective on the options you listed.
Here's some options I see:
Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously.
This seems like the most appealing option if (a) backwards compatibility requires us to keep mutation events, but (b) making them asynchronous doesn't harm that backwards compatibility in significant ways.
Drop support for them with no replacement.
This seems like the most appealing option if mutation events just aren't used.
Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2.
This seems like the most appealing option if we're going to try to coordinate our action on mutation events with third party changes. (Otherwise, the beforeinput/input events can be an independent concern.)
Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html).
I just skimmed this API description, but my take on it is that it's very similar to #1 -- it's still a pretty intrusive set of mutation-related APIs, just an asynchronous one. I'm not convinced by Jonas Sicking's claim that this API is significantly different because it lacks a bubble / capture phase. I don't think that was ever the main problem with mutation events. So, I prefer #1 to #4, since #4 just seems like a more complicated way to avoid the burden of synchronous mutation events. Geoff _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote:
I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway.
However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.).
So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not.
With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.).
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. — Timothy Hatcher
On Aug 9, 2010, at 8:21 PM, Timothy Hatcher wrote:
On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote:
I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway.
However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.).
So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not.
With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.).
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 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. 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. Regards, Maciej [1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMSubtreeModified
On Wed, Aug 11, 2010 at 7:06 AM, Maciej Stachowiak <mjs@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
As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway.
This is the question I'm most interested in. You say the use cases are limited. How do you know? Are you speaking about when you would use mutation events, or do you have data on when authors use them on the web? Is one of the limited use cases on a high traffic web site? Does Mozilla share your opinion? Do others? I have the same questions about Ojan's claim.
However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.).
This is an interesting data point. If we just need an event for an extension to reapply its magic to new content, a global, asynchronous DOMContentChanged event might work. If we introduced an API like that, and gave extensions developers time to update, we could probably remove mutation events without harming extensions. I'd like to give the same kind of consideration to data about web content.
With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.).
I'm not sure this plan makes sense. If we plan to do #2 (remove mutation events), #1 (make mutation events asynchronous) may not be worth the effort. Also, I'm not sure that the best time to remove mutation events depends on what we do (communication) -- it most likely depends on what others do (changing web content not to use mutation events, or not). On the other hand, I would be willing to chip in to see "Friends Don't Let Friends Use DOM Mutation Events" in big letters over highway 101 :). Geoff
On Mon, Aug 9, 2010 at 9:28 PM, Geoffrey Garen <ggaren@apple.com> wrote:
As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway.
This is the question I'm most interested in.
You say the use cases are limited. How do you know? Are you speaking about when you would use mutation events, or do you have data on when authors use them on the web? Is one of the limited use cases on a high traffic web site?
I don't have any data -- just my own intuition at this point.
Does Mozilla share your opinion? Do others?
It would be awesome if Mozilla shared my opinion. We should hook up with them and have a beer-laden discussion. I heard they like beer.
I have the same questions about Ojan's claim.
Good! Let's try to answer them together. For example, in every one of the use cases listed in Wiki, the mutation events are just workarounds for deficiencies of today's Web. Just take a gander: Keeping updated statistics of page DOM -- these are things that a browser should do. If we have a JS developer who writes a selector engine (for justifiable reasons, of course) -- we as browser developers have failed our users. We should be providing this functionality out-of-the-box. Widgetify dynamically created markup -- this cries for a decent behavior attachment construct. Poor man's XBL -- dude, the title says it all. For browser extensions (not for web page authors) -- again, we should be solving this with allowing XBL-like behavior attachment capabilities and certainly not mutation events.
However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.).
This is an interesting data point.
If we just need an event for an extension to reapply its magic to new content, a global, asynchronous DOMContentChanged event might work.
Yes. After extensions launched, I managed to get into fixing some of the mysterious isolated-world-related crashes and was amazed to find out how many extensions use this anti-pattern: document.body.addEventListener("DOMNodeInserted", function() { process() }, false);
If we introduced an API like that, and gave extensions developers time to update, we could probably remove mutation events without harming extensions.
I'd like to give the same kind of consideration to data about web content.
With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.).
I'm not sure this plan makes sense. If we plan to do #2 (remove mutation events), #1 (make mutation events asynchronous) may not be worth the effort.
You're probably right.
Also, I'm not sure that the best time to remove mutation events depends on what we do (communication) -- it most likely depends on what others do (changing web content not to use mutation events, or not).
On the other hand, I would be willing to chip in to see "Friends Don't Let Friends Use DOM Mutation Events" in big letters over highway 101 :).
Yes! Yes! Big Comic Sans letters! :)
Geoff
participants (6)
-
Dimitri Glazkov
-
Geoffrey Garen
-
James Robinson
-
Maciej Stachowiak
-
Ojan Vafai
-
Timothy Hatcher