Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
Sorry for the late reply, this thread flew under my radar.
I made the original name change, because I honestly was entirely confused
about the meaning of "selfOnlyRef" (it's done by Node on Document, so what
is "self"? Why is it needed?) - so I guess we'll have to agree to disagree
which one is clearer. ^_-
That said, I don't have a terribly strong opinion on this (and am not
actively developing WebKit ATM as well).
Also, as Morita-san mentioned, the scope of the implementation has changed,
too, so if you feel strongly about this, please go ahead! :)
Cheers,
- Roland
On Tue, Jun 12, 2012 at 12:14 PM, Hajime Morrita wrote:
> (from right address)
>
> +1 for the rename.
> The original idea to pull guardRef() mechanism up to TreeScope was
> abandoned
> and the size of intended responsibility of TreeScope has become much
> smaller than it originally was.
> So there is no reason to keep it even if the original intention wasn't
> clear.
> --
> morrita
>
> On Tue, Jun 12, 2012 at 12:05 PM, Ojan Vafai wrote:
> >
> >
> > On Mon, Jun 11, 2012 at 6:43 PM, Kentaro Hara
> wrote:
> >>
> >> > I think selfOnlyRef() was a much clearer name.
> >>
> >> I would agree with the rename. (selfOnlyRef() might be removed if I
> could
> >> implement a reference counting that guarantees "Reachable DOM nodes are
> kept
> >> alive", but it is still uncertain. Renaming would make sense to me.)
> >>
> >>
> >> Just a confirmation: In the following example, div.ownerDocument should
> >> return (not null but) iframe.contentDocument. Right?
> >
> >
> > Correct.
> >
> >>
> >>
> >>
> >>
> >>
> >> var iframe = document.getElementById("iframe");
> >> var div = iframe.contentDocument.createElement("div"); // div is not
> yet
> >> in the iframe's document tree
> >> document.body.innerHTML = '';
> >> console.log(div.ownerDocument); // This should be
> iframe.contentDocument.
> >> There is no reference to nodes in the tree, but selfOnlyRef() keeps the
> >> reference to div.ownerDocument.
> >>
> >>
> >>
> >>
> >> On Tue, Jun 12, 2012 at 10:14 AM, Maciej Stachowiak
> wrote:
> >>>
> >>>
> >>> On Jun 11, 2012, at 6:06 PM, Maciej Stachowiak wrote:
> >>>
> >>> > not a self-only reference (at some point renamed to guardRef).
> >>>
> >>> BTW I was able to find where it was renamed but not a good explanation
> of
> >>> why. I think selfOnlyRef() was a much clearer name.
> >>>
> >>> The history seems to be that it was renamed when moved from Document to
> >>> TreeScope (without explanation in the bug or ChangeLog, and apparently
> >>> retaining it's self-only referencing behavior per comments):
> >>>
> >>>http://trac.webkit.org/changeset/82882
> >>>https://bugs.webkit.org/show_bug.cgi?id=57689
> >>>
> >>> Then later it was moved back to Document but retaining the rename:
> >>>
> >>>http://trac.webkit.org/changeset/83123
> >>>https://bugs.webkit.org/show_bug.cgi?id=57994
> >>>
> >>> Would anyone object if I renamed it back? Alternately, could the reason
> >>> for the new name be documented somewhere?
> >>>
> >>> Regards,
> >>> Maciej
> >>>
> >>> ___
> >>> webkit-dev mailing list
> >>> webkit-dev@lists.webkit.org
> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >>
> >>
> >>
> >> --
> >> Kentaro Hara, Tokyo, Japan (http://haraken.info)
> >>
> >> ___
> >> 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
[webkit-dev] Making Webkit compliant with HTML5 new features
Hello all, I am actually novice in webkit but i want to learn *make webkit (on webkit.org) compliant with new HTML5 Tags & Features. *Could anyone guide me through the steps to start with ? Kindly suggest if i haven't put things inappropriately. Thanks & Regards, Navanshu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making Webkit compliant with HTML5 new features
On Fri, Jun 15, 2012 at 3:18 AM, Navanshu Mahor wrote: > Hello all, > > I am actually novice in webkit but i want to learn *make webkit (on > webkit.org) compliant with new HTML5 Tags & Features. > *Could anyone guide me through the steps to start with ? > > Kindly suggest if i haven't put things inappropriately. > Filing bugs on bugs.webkit.org for things that what make WebKit not compliant with the HTML5 specifications is a good starting point. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Jun 15, 2012, at 12:12 AM, Roland Steiner wrote: > I made the original name change, because I honestly was entirely confused > about the meaning of "selfOnlyRef" (it's done by Node on Document, so what is > "self"? Why is it needed?) A good rule of thumb, the one that I use, is that a name like this shouldn't be changed when you still don’t understand the meaning of the original name. Changing a name you fully understand, but find unclear, is OK. I can see why “selfOnlyRef” is not clear to you, and I agree with Maciej that “guardRef” is even less clear. We can probably come up with a better name. For clarity, what we want is a name that means “parent only, not including children”. My personal rule of thumb stems largely from my experience on a project 20 years ago where I was confused by the term “page frame” and because I found it unclear changed it one I found clearer “physical page” and also introduced the term “logical page”. I later learned that “page frame” was a term of art, one that I would have learned if I had taken an OS class, and I would have been better off if I had held off on changing the name until I understood the original one. -- Darin___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making Webkit compliant with HTML5 new features
On Jun 15, 2012, at 7:23 AM, Ryosuke Niwa wrote: > Filing bugs on bugs.webkit.org for things that make WebKit not compliant with > the HTML5 specifications is a good starting point. Another useful task is to learn to write good regression tests, and write tests that demonstrate the problems you find as well as covering other related behavior in WebKit. You can contribute those tests in patches in bugs.webkit.org. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Fri, Jun 15, 2012 at 9:30 AM, Darin Adler wrote: > On Jun 15, 2012, at 12:12 AM, Roland Steiner wrote: > > I made the original name change, because I honestly was entirely confused > about the meaning of "selfOnlyRef" (it's done by Node on Document, so what > is "self"? Why is it needed?) > > > A good rule of thumb, the one that I use, is that a name like this > shouldn't be changed when you still don’t understand the meaning of the > original name. Changing a name you fully understand, but find unclear, is > OK. > > I can see why “selfOnlyRef” is not clear to you, and I agree with Maciej > that “guardRef” is even less clear. We can probably come up with a better > name. For clarity, what we want is a name that means “parent only, not > including children”. > How about refAvoidingCyclesWithDescendents or refWithoutRefingDescendents? Here's the comment right above the declaration / definition of guardRef: // Nodes belonging to this document hold guard references - // these are enough to keep the document from being destroyed, but // not enough to keep it from removing its children. This allows a // node that outlives its document to still have a valid document // pointer without introducing reference cycles. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Jun 15, 2012, at 9:47 AM, Ryosuke Niwa wrote: > // Nodes belonging to this document hold guard references - > // these are enough to keep the document from being destroyed, but > // not enough to keep it from removing its children. This allows a > // node that outlives its document to still have a valid document > // pointer without introducing reference cycles. refDocumentButNotChildren? I guess that makes it sound like the ordinary ref calls ref on children. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Jun 15, 2012, at 12:12 AM, Roland Steiner wrote: > Sorry for the late reply, this thread flew under my radar. > > I made the original name change, because I honestly was entirely confused > about the meaning of "selfOnlyRef" (it's done by Node on Document, so what is > "self"? Why is it needed?) - so I guess we'll have to agree to disagree which > one is clearer. ^_- I can see how the name is less than perfectly clear, but since it's generally called as doc->selfOnlyRef(), I think it's pretty clear that the Node doing the calling can't be the relevant "self". To me, guardRef() sounded like something for short-term protection in the scope of a function (the way we often use a local RefPtr on an object that may be destroyed), rather than like what it actually does. I think the main downside to selfOnlyRef() is that it's not fully clear what "self-only" means even if you know what "self" is. But it's hard to explain fully in a function name w/o excess verbosity. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Fri, Jun 15, 2012 at 9:49 AM, Darin Adler wrote: > On Jun 15, 2012, at 9:47 AM, Ryosuke Niwa wrote: > > > // Nodes belonging to this document hold guard references - > > // these are enough to keep the document from being destroyed, but > > // not enough to keep it from removing its children. This allows a > > // node that outlives its document to still have a valid document > > // pointer without introducing reference cycles. > > refDocumentButNotChildren? I guess that makes it sound like the ordinary > ref calls ref on children. > Maybe refToOnlyKeepOwnerDocument or refToKeepOwnerDocument if we're going that route? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unprefixing DOM MutationObservers, and looking for help from port maintainers
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 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Jun 15, 2012, at 10:15 AM, Maciej Stachowiak wrote: > But it's hard to explain fully in a function name w/o excess verbosity. I think my favorite excess verbosity version is refDocumentButNotOtherNodes. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unprefixing DOM MutationObservers, and looking for help from port maintainers
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 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 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@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] Unprefixing DOM MutationObservers, and looking for help from port maintainers
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 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 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 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@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] Unprefixing DOM MutationObservers, and looking for help from port maintainers
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" 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 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 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 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@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] Unprefixing DOM MutationObservers, and looking for help from port maintainers
On Fri, Jun 15, 2012 at 11:15 AM, Ryosuke Niwa wrote: > Great! > > What is the difference in handling the style attribute? It's this test: http://trac.webkit.org/browser/trunk/LayoutTests/fast/mutation/observe-attributes.html#L741 Firefox mutates the attribute even though nothing changed. Per Olli on #whatwg, they're just following the HTML spec here (http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-style-attribute): "Mutating the CSSStyleDeclaration object must create a style attribute on the element (if there isn't one already) and then change its value to be a value representing the serialized form of the CSSStyleDeclaration object." I don't think this is likely to cause any problems that haven't already cropped up over the years from this difference. > 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) It'd definitely be nice to push these upstream, I agree. And I also don't think this should block unprefixing :) > > - Ryosuke > > On Jun 15, 2012 11:09 AM, "Adam Klein" 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 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 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 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@lists.webkit.org >> >> http://lists.webkit.org/mailman/listinfo.
[webkit-dev] EditBugs permission
Hey, Could i get EditBugs for my bugzilla account? (pab...@motorola.com) I'm not a commiter, but i've contributed a bunch of patches already. Thanks! -- pablo flouret motorola | webkit / browser team ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Jun 15, 2012, at 10:31 AM, Darin Adler wrote: > On Jun 15, 2012, at 10:15 AM, Maciej Stachowiak wrote: > >> But it's hard to explain fully in a function name w/o excess verbosity. > > I think my favorite excess verbosity version is refDocumentButNotOtherNodes. Things I dislike about that one: - Seems to imply that normal ref() refs other nodes, which it doesn't really (though it does act as a refcount controlling whether the document will possibly remove its children while still alive) - Extremely vague about which other nodes, to the point of giving the implication that ref() might ref completely arbitrary other nodes. Or else it gives the impression that it's just the right ref to use on Document but not on other classes. - No obvious sensible name for the corresponding refcount data member (m_refDocumentButNotOtherNodesCount does not seem clear to me). The way I'd fully explain the design is as follows: - Document has two refcounts, the normal refcount and the self-only refcount. - The document will not be destroyed so long as either refcount is nonzero. - If the normal refcount is zero but the self-only refcount is zero, the document will remove all of its own children. - Descendant nodes of the document should hold a self-only ref to their owner document, not a regular ref, to avoid reference cycles. I am not sure how to get the key points across without being accurate or misleading. A version that I think explains the complete design without saying anything false or misleading: refTheDocumentItselfButUnlikeTheRegularRefDontPreventTheDocumentsChildrenFromBeingRemovedToAvoidCyclesWhenRefingTheOwnerDocument To make a reasonable name we probably need to focus on one of these aspects. Perhaps one approach is to focus on when and why you should use this call, rather than what it does: refAsOwnerDocument() / m_refCountAsOwnerDocument (or m_ownerDocumentRefCount) refAvoidingCycles() (or cycleAvoidingRef()) / m_cycleAvoidingRefCount Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak wrote: > > I am not sure how to get the key points across without being accurate or > misleading. A version that I think explains the complete design without > saying anything false or misleading: > > > refTheDocumentItselfButUnlikeTheRegularRefDontPreventTheDocumentsChildrenFromBeingRemovedToAvoidCyclesWhenRefingTheOwnerDocument > > To make a reasonable name we probably need to focus on one of these > aspects. Perhaps one approach is to focus on when and why you should use > this call, rather than what it does: > > refAsOwnerDocument() / m_refCountAsOwnerDocument (or > m_ownerDocumentRefCount) > refAvoidingCycles() (or cycleAvoidingRef()) / m_cycleAvoidingRefCount > We probably need to qualify kinds of cycles we're avoiding: ones through descendents (or subtree); e.g. this doesn't avoid cycles with JSC/V8 objects. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Jun 15, 2012, at 12:22 PM, Ryosuke Niwa wrote: > On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak wrote: > I am not sure how to get the key points across without being accurate or > misleading. A version that I think explains the complete design without > saying anything false or misleading: > > refTheDocumentItselfButUnlikeTheRegularRefDontPreventTheDocumentsChildrenFromBeingRemovedToAvoidCyclesWhenRefingTheOwnerDocument > > To make a reasonable name we probably need to focus on one of these aspects. > Perhaps one approach is to focus on when and why you should use this call, > rather than what it does: > > refAsOwnerDocument() / m_refCountAsOwnerDocument (or m_ownerDocumentRefCount) > refAvoidingCycles() (or cycleAvoidingRef()) / m_cycleAvoidingRefCount > > We probably need to qualify kinds of cycles we're avoiding: ones through > descendents (or subtree); e.g. this doesn't avoid cycles with JSC/V8 objects. That's one reason I like refAsOwnerDocument() slightly better. It tells you when to use it, and when Node.cpp does m_document->refAsOwnerDocument(), it will make sense in context. However, if you wanted to make the other version more exactingly precise, you could say something like refAvodingCyclesWithDescendents(). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EditBugs permission
Done. Folks should feel free to ping me on #webkit rather than emailing webkit-dev abou this sort of thing. Adam On Fri, Jun 15, 2012 at 12:03 PM, Pablo Flouret wrote: > Hey, > > Could i get EditBugs for my bugzilla account? (pab...@motorola.com) > > I'm not a commiter, but i've contributed a bunch of patches already. > > Thanks! > > -- > pablo flouret > motorola | webkit / browser team > ___ > 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] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Fri, Jun 15, 2012 at 12:40 PM, Maciej Stachowiak wrote: > On Jun 15, 2012, at 12:22 PM, Ryosuke Niwa wrote: > > On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak wrote: >> >> I am not sure how to get the key points across without being accurate or >> misleading. A version that I think explains the complete design without >> saying anything false or misleading: >> >> >> refTheDocumentItselfButUnlikeTheRegularRefDontPreventTheDocumentsChildrenFromBeingRemovedToAvoidCyclesWhenRefingTheOwnerDocument >> >> To make a reasonable name we probably need to focus on one of these >> aspects. Perhaps one approach is to focus on when and why you should use >> this call, rather than what it does: >> >> refAsOwnerDocument() / m_refCountAsOwnerDocument (or >> m_ownerDocumentRefCount) >> refAvoidingCycles() (or cycleAvoidingRef()) / m_cycleAvoidingRefCount >> > > We probably need to qualify kinds of cycles we're avoiding: ones through > descendents (or subtree); e.g. this doesn't avoid cycles with JSC/V8 > objects. > > > That's one reason I like refAsOwnerDocument() slightly better. It tells > you when to use it, and when Node.cpp does > m_document->refAsOwnerDocument(), it will make sense in context. > Yeah, refAsOwnerDocument() sounds good to me. However, if you wanted to make the other version more exactingly precise, > you could say something like refAvodingCyclesWithDescendents(). > Coincidentally, that's one of suggestions I made so I'm fine with that version as well :) - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Reflecting pixel delta "distance" in ImageDiff
I would like to change chromium's ImageDiff to reflect the magnitude of pixel changes. Currently, if the pixel has any difference, the entire pixel is marked as 100% red. I'd like to change it so that miniscule difference are 20% red and large differences are 100% red. Looking at the code for CG, gtk and Win versions of ImageDiff, I think they already do something similar. Is this correct? Would anyone be opposed to such a change? See the attached image for an example of how this could assist in debugging regressions. It would certainly be enormously useful in my color management efforts. Thanks, Tony The CL in question is https://bugs.webkit.org/show_bug.cgi?id=89253 <>___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reflecting pixel delta "distance" in ImageDiff
On Fri, Jun 15, 2012 at 4:24 PM, Tony Payne wrote: > I would like to change chromium's ImageDiff to reflect the magnitude of > pixel changes. Currently, if the pixel has any difference, the entire pixel > is marked as 100% red. I'd like to change it so that miniscule difference > are 20% red and large differences are 100% red. Looking at the code for CG, > gtk and Win versions of ImageDiff, I think they already do something > similar. Is this correct? > > Would anyone be opposed to such a change? See the attached image for an > example of how this could assist in debugging regressions. It would > certainly be enormously useful in my color management efforts. > People with Protanomaly like myself won't be too happy about it. I'm already having a really hard time finding the red pixels on diffs without zooming. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reflecting pixel delta "distance" in ImageDiff
On Fri, Jun 15, 2012 at 4:27 PM, Ryosuke Niwa wrote: > On Fri, Jun 15, 2012 at 4:24 PM, Tony Payne wrote: > >> I would like to change chromium's ImageDiff to reflect the magnitude of >> pixel changes. Currently, if the pixel has any difference, the entire pixel >> is marked as 100% red. I'd like to change it so that miniscule difference >> are 20% red and large differences are 100% red. Looking at the code for CG, >> gtk and Win versions of ImageDiff, I think they already do something >> similar. Is this correct? >> >> Would anyone be opposed to such a change? See the attached image for an >> example of how this could assist in debugging regressions. It would >> certainly be enormously useful in my color management efforts. >> > > People with Protanomaly like myself won't be too happy about it. I'm > already having a really hard time finding the red pixels on diffs without > zooming. > Fair enough, but that doesn't address the basic premise of distinguishing small deltas from large deltas. I'm sure we can find a UI that will work that achieves the desired goal ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reflecting pixel delta "distance" in ImageDiff
On Fri, Jun 15, 2012 at 8:24 PM, Tony Payne wrote: > Looking at the code for CG, gtk and Win versions of ImageDiff, I think they > already do something similar. Is this correct? The GTK and Efl produces a grayscale image, where the pixel goes from black (no difference) to white, gradually, proportional to the euclidean distance between both pixel colors inside a RGB cube (sort of, as alpha channel is also considered). -- Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reflecting pixel delta "distance" in ImageDiff
On Fri, Jun 15, 2012 at 8:27 PM, Ryosuke Niwa wrote: > People with Protanomaly like myself won't be too happy about it. I'm already > having a really hard time finding the red pixels on diffs without zooming. Perhaps generating a list of rectangles where there are differences would help produce some interactive result with some marching ants bounding boxes that when clicked, zooms in to show the details? Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
