Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
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?
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
[webkit-dev] Six new layout tests missing expected results
Who knows what is up with these? I'm guessing they came from the same patch. Please fix if you know what these are about. fast/table/simple_paint.html - new tables/hittesting/filltable-emptycells.html - new tables/hittesting/filltable-levels.html - new tables/hittesting/filltable-outline.html - new tables/hittesting/filltable-rtl.html - new tables/hittesting/filltable-stress.html - new ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Six new layout tests missing expected results
Fady, it looks ( http://trac.webkit.org/search?q=tables/hittesting/filltable-emptycells.html) like this is due to your patch. dave On Wed, Aug 18, 2010 at 7:32 PM, Maciej Stachowiak m...@apple.com wrote: Who knows what is up with these? I'm guessing they came from the same patch. Please fix if you know what these are about. fast/table/simple_paint.html - new tables/hittesting/filltable-emptycells.html - new tables/hittesting/filltable-levels.html - new tables/hittesting/filltable-outline.html - new tables/hittesting/filltable-rtl.html - new tables/hittesting/filltable-stress.html - new ___ 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] Six new layout tests missing expected results
Yep. It's his. He doesn't have a Mac, so he's been trying to collect results from the bot pretty much all day today. Given that he's not a committer either, that's twice as hard :) :DG On Wed, Aug 18, 2010 at 7:37 PM, David Levin le...@chromium.org wrote: Fady, it looks (http://trac.webkit.org/search?q=tables/hittesting/filltable-emptycells.html) like this is due to your patch. dave On Wed, Aug 18, 2010 at 7:32 PM, Maciej Stachowiak m...@apple.com wrote: Who knows what is up with these? I'm guessing they came from the same patch. Please fix if you know what these are about. fast/table/simple_paint.html - new tables/hittesting/filltable-emptycells.html - new tables/hittesting/filltable-levels.html - new tables/hittesting/filltable-outline.html - new tables/hittesting/filltable-rtl.html - new tables/hittesting/filltable-stress.html - new ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Six new layout tests missing expected results
So sorry. I had to leave before I got in another patch that fixed the problem. Will have it fixed tomorrow. Fady On Wed, Aug 18, 2010 at 11:08 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Yep. It's his. He doesn't have a Mac, so he's been trying to collect results from the bot pretty much all day today. Given that he's not a committer either, that's twice as hard :) :DG On Wed, Aug 18, 2010 at 7:37 PM, David Levin le...@chromium.org wrote: Fady, it looks ( http://trac.webkit.org/search?q=tables/hittesting/filltable-emptycells.html ) like this is due to your patch. dave On Wed, Aug 18, 2010 at 7:32 PM, Maciej Stachowiak m...@apple.com wrote: Who knows what is up with these? I'm guessing they came from the same patch. Please fix if you know what these are about. fast/table/simple_paint.html - new tables/hittesting/filltable-emptycells.html - new tables/hittesting/filltable-levels.html - new tables/hittesting/filltable-outline.html - new tables/hittesting/filltable-rtl.html - new tables/hittesting/filltable-stress.html - new ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
