[webkit-dev] Unprefixing DOM MutationObservers, and looking for help from port maintainers

[Ryosuke Niwa]

Great!

What is the difference in handling the style attribute?

Also, can we convert existing tests to use testharness.js and submit them
to W3C? That way, we can help other browser vendors implement it
"correctly" when they do. (of course, this shouldn't block unprefixing the
API)

- Ryosuke
On Jun 15, 2012 11:09 AM, "Adam Klein" <adamk at chromium.org> wrote:

> I was working closely with Olli Pettay when he was putting together
> the tests for Firefox, and we passed all of those (as of a couple
> months ago; our code hasn't changed since then). Just ran through our
> tests with Firefox Aurora and everything passed modulo differences in
> supported features (they don't support WebSQL or FileSystem API which
> we use in a few tests; there were some minor differences in handling
> of the style attribute, but nothing that looks likely to cause
> compatibility issues (whitespace)).
>
> I've uploaded a proposed patch at
> https://bugs.webkit.org/show_bug.cgi?id=89231 (wanted to give it a
> shot through the EWS bots). I've yet to implement a way to turn off
> the unprefixing for ports that aren't yet done, suggestions on how to
> do that most simply are appreciated.
>
> - Adam
>
> On Fri, Jun 15, 2012 at 10:48 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > Before unprefixing it, can we make sure we also pass Mozilla's tests and
> > vice versa? Mutation events was a huge mess partially because browsers
> > didn't interoperate. I'd like to make sure this API interoperates well
> from
> > day 1.
> >
> > - Ryosuke
> >
> > On Fri, Jun 15, 2012 at 10:31 AM, Adam Klein <adamk at chromium.org> wrote:
> >>
> >> An update: it appears that the GTK and EFL ports have added at least
> >> basic support for end-of-task delivery, in
> >> http://trac.webkit.org/changeset/108628 and
> >> http://trac.webkit.org/changeset/110568. They now pass all
> >> MutationObserver tests. Do these tests pass in the actual browsers
> >> built from GTK and EFL, or only DRT?
> >>
> >> On Fri, Jun 8, 2012 at 2:16 PM, Adam Klein <adamk at chromium.org> wrote:
> >> > Hi webkit-dev,
> >> >
> >> > DOM MutationObservers (see meta bug
> >> > https://bugs.webkit.org/show_bug.cgi?id=68729) have been shipping as
> >> > WebKitMutationObserver in Chromium since earlier this year. The
> >> > feature is fully specced as part of DOM4
> >> > (http://www.w3.org/TR/domcore/#mutation-observers) and is implemented
> >> > in Firefox. Mozilla has also recently unprefixed their version of the
> >> > API (https://bugzilla.mozilla.org/show_bug.cgi?id=749920), and I'd
> >> > like to do the same (https://bugs.webkit.org/show_bug.cgi?id=85161).
> >> >
> >> > The tricky part is that while the Chromium version is complete and
> >> > compatible with Firefox, there's one piece missing from all other
> >> > ports (https://bugs.webkit.org/show_bug.cgi?id=78290). The short
> >> > version is that each port needs to be able to run some code
> >> > (delivering mutations) at the end of every task (see
> >> >
> >> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2
> ,
> >> > step 4 "Perform a microtask checkpoint"). Without this code, mutations
> >> > due to user input are not delivered in a timely fashion.
> >> >
> >> > It's easy for Chromium to do this because we have our own MessageLoop
> >> > abstraction wrapping the native event loops on various platforms, so
> >> > our definition of end-of-task is easy to define. But implementing this
> >> > properly is likely to be slightly different for every port.
> >> >
> >> > In the short term, my plan is to add the unprefixed version (in
> >> > addition to the prefixed) of MutationObserver when PLATFORM(CHROMIUM)
> >> > is enabled. But I'd like to help other ports implement this
> >> > appropriately, and provide the unprefixed version there too. Please
> >> > let me know how I can be of assistance.
> >> >
> >> > Let me know if you have questions or concerns,
> >> > Adam Klein
> >> _______________________________________________
> >> webkit-dev mailing list
> >> webkit-dev at lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120615/3cc0c575/attachment.html>