Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-18 Thread Ojan Vafai
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


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-18 Thread Ryosuke Niwa
On Wed, Aug 18, 2010 at 2:31 PM, Ojan Vafai o...@chromium.org wrote:

 My intuition is that very few sites or extensions actually depend on them
 being synchronous.


I agree. I worked on some extension app this spring but all I needed to know
was when the subtree of certain nodes change so that I can go ahead and
modify them. There was no need to prevent the change or catch synchronously.

That alone, I think would address the majority of mutation-event related
 crashing and does not prevent us from adding newer, better APIs.


Agreed. If we can postpone all mutation events until the end of each compose
edit command, we'll be able to prevent the majority of crashes.

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.


Ditto.

Best,
Ryosuke Niwa
Software Engineer
Google Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-11 Thread Maciej Stachowiak

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-10 Thread Dimitri Glazkov
On Mon, Aug 9, 2010 at 9:28 PM, Geoffrey Garen gga...@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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-09 Thread Ojan Vafai
On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth aba...@webkit.org wrote:

 On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak m...@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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-09 Thread James Robinson
On Mon, Aug 9, 2010 at 4:39 PM, Ojan Vafai o...@chromium.org wrote:

 On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth aba...@webkit.org wrote:

 On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak m...@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


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-09 Thread Geoffrey Garen
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


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-09 Thread Dimitri Glazkov
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 gga...@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


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-09 Thread Timothy Hatcher
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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?

2010-08-09 Thread Geoffrey Garen
 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev