[webkit-dev] Unprefixing Blob.webkitSlice() ?
Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from start, length to start, end semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unprefixing Blob.webkitSlice() ?
Happy to see us support unprefixed too. With other vendors on board, it seems like a straightforward addition to the platform. I'm not sure if you are proposing to also remove the prefixed form. I'm not sure what it would take to remove the prefixed version. We'd need some way to know when it is safe to remove it. We could surely instrument the code to measure its use relative to the unprefixed form once it is widely deployed. -Darin On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda kin...@chromium.org wrote: Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from start, length to start, end semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ 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 Blob.webkitSlice() ?
On Mon, Jun 11, 2012 at 3:34 PM, Darin Fisher da...@chromium.org wrote: Happy to see us support unprefixed too. With other vendors on board, it seems like a straightforward addition to the platform. I'm not sure if you are proposing to also remove the prefixed form. I'm not sure what it would take to remove the prefixed version. We'd need some way to know when it is safe to remove it. We could surely instrument the code to measure its use relative to the unprefixed form once it is widely deployed. We've been shipping the prefixed version for a year now (in Chrome 11-19 and in Safari 5), so I propose keeping the prefixed version too for now, but to start showing a deprecation message to encourage migration. -Darin On Sun, Jun 10, 2012 at 11:17 PM, Kinuko Yasuda kin...@chromium.orgwrote: Hi WebKit folks, We've been vendor-prefixing Blob.slice() since we changed the semantics of slice() to make it alike Array.slice, i.e. from start, length to start, end semantics in r83873 [1]. The non-prefixed version had only been shipped in Chrome and must have helped apps migrate into the new semantics. However Mozilla has now unprefixed it since Gecko/FireFox 13.0 [2], Opera said they are going to unprefix it with the new semantics [3] and IE compatibility test has a set of Blob.slice tests which require unprefixed slice [4]. Maybe it's becoming a good time to unprefix slice() again? https://bugs.webkit.org/show_bug.cgi?id=78111 [1] http://trac.webkit.org/changeset/83873 [2] https://developer.mozilla.org/en/DOM/Blob#Notes_on_the_slice()_implementations [3] https://bugs.webkit.org/show_bug.cgi?id=78111 [4] http://samples.msdn.microsoft.com/ietestcenter/#fileapi Kinuko ___ 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] European WebKit Hackathon Bucharest 2012
Hello WebKit community, We want to announce a European WebKit Hackathon event hosted by Adobe. The event will take place in Adobe office in Bucharest on September 20th - 22nd. We hope that this hackathon will offer attendees the opportunity to know each other better, share WebKit expertise, and help WebKit move forward by fixing bugs, writing tests, and develop HTML5 prototypes based on WebKit. You can find more information about the event: http://webkithackathon2012.eventbrite.comhttp://webkithackathon2012.eventbrite.com// We hope to see you there, Cheers, Mihnea Ovidenie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
Hi, I realized that there are a whole bunch of tests in LayoutTests/css3 that use layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to mean that they're our own tests. However, css3/selectors3 is an imported W3C test suite. It's very confusing to mix imported tests and WebKit's own tests. Can we put the imported W3C tests in imported-w3c directory as proposed earlier? 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] Using the WebExposed keyword for web-facing changes
On Mon, Jun 11, 2012 at 2:08 AM, TAMURA, Kent tk...@chromium.org wrote: Do you want WebExposed for a simple bug fix of an existing feature? Do you want it for bugs with no patches? If the change might impact Web Developers - yes. Of course, use your own judgement here; it won't have much benefit for minor fixes on a feature in very early stages of development which is still disabled on all major ports. However, when in doubt, it's better to be on the safe side and add the label. Using it for bugs without patches is fine, of course. Thanks, Peter On Sat, Jun 9, 2012 at 5:24 AM, Peter Beverloo pe...@chromium.org wrote: Hi webkit-dev, *If you work on web-facing features, or run into another bug which does, please consider adding the WebExposed keyword to it.* Many of you will be familiar with my WebKit updates, which are now also being published on the WebKit blog. Writing these involves reading every commit that lands in WebKit's repository. Last year, May counted 2,126 revisions. This year there were 3,068. As a result of the steep increase in volume, it's becoming increasingly hard for all parties to keep up -- Web(Kit) developers, ports and all other interested parties. Not every one of them has time to read through all changes. In an effort to increase visibility of Web Platform facing changes, I'd like to introduce the WebExposed keyword. It is intended to be applied to any bug which introduces, modifies (including behavioral changes) or removes features important to Web developers, such as DOM properties and methods, JavaScript features and CSS properties and values. https://bugs.webkit.org/buglist.cgi?keywords=WebExposed Increased visibility of these changes has a number of advantages. Firstly, Web Developers will have more insight in what's happening in WebKit. The changes will be visible on the bug list itself, but also through the RSS feed Bugzilla will curate for it. Furthermore, it may be used as an overview for ports to keep track of the web-facing changes which happen during their release cycles, and it will also come in useful for evangelizing features, writing documentation and managing outreach. With work being done by many vendors in many areas of WebCore, I'm hoping the keyword can become a valuable aid in this respect. If you work on web-facing features, or run into another bug which does, please consider adding the WebExposed keyword to it. This of course isn't mandatory, but it will help others who are interested in keeping track. Thanks, Peter ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK+ port's help needed to get rid of FAIL test expectation
On 2012-06-10 19:09, Žan Doberšek wrote: I think it would suffice to replace all the FAIL occurrences with TEXT, except for the failing reftests - those should have FAIL turned into IMAGE. Gtk bots don't run pixel tests yet so any other IMAGE failures could perhaps be addressed at later time. I agree with that approach. Philippe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
I think imported tests should be outside of LayoutTests/fast. Simon On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote: Hi, I realized that there are a whole bunch of tests in LayoutTests/css3 that use layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to mean that they're our own tests. However, css3/selectors3 is an imported W3C test suite. It's very confusing to mix imported tests and WebKit's own tests. Can we put the imported W3C tests in imported-w3c directory as proposed earlier? 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
On Mon, Jun 11, 2012 at 3:09 PM, Simon Fraser simon.fra...@apple.com wrote: I think imported tests should be outside of LayoutTests/fast. I agree a dedicated folder seems more appropriate. My two cents. Simon On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote: Hi, I realized that there are a whole bunch of tests in LayoutTests/css3 that use layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to mean that they're our own tests. However, css3/selectors3 is an imported W3C test suite. It's very confusing to mix imported tests and WebKit's own tests. Can we put the imported W3C tests in imported-w3c directory as proposed earlier? 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
On 6/11/12 11:11 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jun 11, 2012 at 3:09 PM, Simon Fraser simon.fra...@apple.com wrote: I think imported tests should be outside of LayoutTests/fast. I agree a dedicated folder seems more appropriate. My two cents. Simon On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote: Hi, I realized that there are a whole bunch of tests in LayoutTests/css3 that use layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to mean that they're our own tests. However, css3/selectors3 is an imported W3C test suite. It's very confusing to mix imported tests and WebKit's own tests. Can we put the imported W3C tests in imported-w3c directory as proposed earlier? Can we just create an imported-w3c folder at the same level as LayoutTests? 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ 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] Can we distinguish imported tests in LayoutTests/css3 ?
On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein jac...@adobe.com wrote: Can we just create an imported-w3c folder at the same level as LayoutTests? You mean at trunk? I don't think that makes sense, and our testing infrastructure doesn't support that. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
On 6/11/12 2:24 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com wrote: Can we just create an imported-w3c folder at the same level as LayoutTests? You mean at trunk? I don't think that makes sense, and our testing infrastructure doesn't support that. Ah, ok. In that case the next best option is to put it within LayoutTests. Are there any objections to this idea? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
On Mon, Jun 11, 2012 at 2:25 PM, Jacob Goldstein jac...@adobe.com wrote: On 6/11/12 2:24 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein jac...@adobe.comwrote: Can we just create an imported-w3c folder at the same level as LayoutTests? You mean at trunk? I don't think that makes sense, and our testing infrastructure doesn't support that. Ah, ok. In that case the next best option is to put it within LayoutTests. Are there any objections to this idea? Yes, I object to that. If we had created imported-w3c under LayoutTests, then I'd have to specify multiple directories to run tests for each component. e.g. if we had imported Aryeh's editing API tests from W3C repository, then I have to run tests in both LayoutTests/editing and LayoutTests/imported-w3c/editing/ It would be much better if imported-w3c was inside editing so that run-webkit-tests editing would run all editing tests. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
On Mon, Jun 11, 2012 at 2:24 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein jac...@adobe.com wrote: Can we just create an imported-w3c folder at the same level as LayoutTests? You mean at trunk? I don't think that makes sense, and our testing infrastructure doesn't support that. Technically, it does (at least NRWT does), but I wouldn't recommend it. NRWT is designed to allow tests to live in multiple repos, but it seems like all of the tests in the webkit repo should be under a single top-level dir. -- Dirk - Ryosuke ___ 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] Can we distinguish imported tests in LayoutTests/css3 ?
On Mon, Jun 11, 2012 at 2:33 PM, Dirk Pranke dpra...@chromium.org wrote: Technically, it does (at least NRWT does), but I wouldn't recommend it. NRWT is designed to allow tests to live in multiple repos, but it seems like all of the tests in the webkit repo should be under a single top-level dir. I don't think old-run-webkit-tests supports that, not that it'll be too hard to support it. Regardless I agree with your point that all tests should be in single directory although I can see we can separate tests into two groups: regression tests and conformance tests. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
On 6/11/12 2:37 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Mon, Jun 11, 2012 at 2:33 PM, Dirk Pranke dpra...@chromium.orgmailto:dpra...@chromium.org wrote: Technically, it does (at least NRWT does), but I wouldn't recommend it. NRWT is designed to allow tests to live in multiple repos, but it seems like all of the tests in the webkit repo should be under a single top-level dir. I don't think old-run-webkit-tests supports that, not that it'll be too hard to support it. Regardless I agree with your point that all tests should be in single directory although I can see we can separate tests into two groups: regression tests and conformance tests. That sounds fine to me. I believe that the idea floated at the contributor's meeting was to put an imported folder within each feature/topic area. That way you can run the top level folder for a feature area and get both imported and WebKit-specific tests. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] can we stop using Skipped files?
On Jun 10, 2012, at 9:26 AM, Ojan Vafai o...@chromium.org wrote: On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen kbal...@webkit.org wrote: So the unit tests are superfluous. In particular, if I had to pick between only having unit tests or only having regression tests, I might pick unit tests. But if I already have regression tests then I'm unlikely to want to incur technical debt to build unit tests, particularly since unit tests requiring changing the infrastructure to make the code more testable, which then leads to the problems listed above. There are many code paths are used rarely. In practice, we were having regressions frequently when people modified the code. Since the codebase has been unittested, the rate of regressions has gone down considerably. The time you spend dealing with tests is considerably less than the time you spend rolling patches in an out as you encounter different edge cases that different configurations/flags hit. A quick note to unittests. I think it's easy to define a hard limit for unittests, which is that: if I want to add a feature, or some customizing option for a particular port, it should be less effort to write the unittest than to write the actual code. I heard from my colleges a few times that it's not always the case with nrwt. I can imagine that it's not trivial to setup the unittest system for a module that has not been unittested so far but I think it should rather be the job of those who are actively working on the test harness, not of those who just need some work to be done for their port. While this is a nice ideal to strive for, I don't think this ever plays out for testing on any project, e.g. it is very frequently harder to write tests for my WebCore changes than to make the change itself. Certainly anything we can do to make testing easier is better, but I don't see NRWT as more difficult to test than any other code in the WebKit project. WebKit has a policy of every change requiring tests. I don't see why tooling should be any different. It's unfortunate that NRWT started with 0 tests, so there are still (very few now!) parts that aren't tested. It's hard to test those parts if that's what your modifying. However, it's *especially* for the cases of port-specific code that need testing. Those are exactly the codepaths that break from lack of testing. Do we have some data that shows NRWT suffering fewer regressions (per unit time or per N changes) than ORWT? I am strongly in favor of automated tests in general, but I'm skeptical of it here for two reasons: 1) I have found the hackability of anything involving webkitpy and its unit tests to be poor. It takes a long time to make a simple change, and the need to add tests or modify tests is certainly part of it. 2) For code that ships to end-users or third parties, I am a strong advocate of comprehensive testing. I think testing is worthwhile even if it were hypothetically the case that faith-based programming was less total work. That is so because we are trading off the time of a couple of hundred WebKit engineers for quality of software experienced by hundreds of millions of users. So it's worth it to incur significant test infrastructure costs to benefit a much greater number of users. But for the case of internal tools, I think the tradeoff is fundamentally different. The costs of maintaining test infrastructure and the costs of dealing with regressions are borne by more or less the same set of people. So if the work to maintain unit tests is greater than the cost of just dealing with whatever regressions slip through, then it's probably not worth it. My own gut feeling is that ORWT never experienced enough regressions to justify the cost of a unit testing system. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree traversal on detached nodes
On Jun 6, 2012, at 6:27 PM, Darin Adler da...@apple.com wrote: On Jun 6, 2012, at 6:14 PM, Kentaro Hara hara...@chromium.org wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I vaguely recall that I originally implemented rule (b) for WebKit, and at the time I did it because: (1) The exact behavior in this case seemed unimportant; I couldn't find any sites depending on it, nor did it seem likely that they would. (2) It was the simplest apparent way to avoid leaking certain kinds of cycles that span GC and refcounting (I don't remember the details and this is likely no longer applicable)/ (3) It seemed that keeping ancestors alive would have the potential to hold large amounts of memory when much of it was unneeded. An even more extreme example of (3) would result if both parentNode and ownerDocument were strong references, and ownerDocument was made to be a real reference, not a self-only reference (at some point renamed to guardRef). Then keeping a single node that was in an isolated DOM subtree alive would also keep that whole document alive. I am not sure what other browsers do in this case. Of course, predictability might outweigh the potential memory use issues. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Rename of selfOnlyRef to guardRef - ok if I change it back? (was Re: DOM tree traversal on detached nodes)
On Jun 11, 2012, at 6:06 PM, Maciej Stachowiak m...@apple.com 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
Re: [webkit-dev] DOM tree traversal on detached nodes
Thanks Maciej I am trying to implement a WIP patch that guarantees Reachable DOM nodes are kept alive, without regressing performance nor without adding member variables to Node objects. The patch will remove guardRef() as a natural consequence. Although I'm not 100% sure if the work succeeds or not in terms of performance, I'll upload the patch and a document in a week or so. On Tue, Jun 12, 2012 at 10:06 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 6, 2012, at 6:27 PM, Darin Adler da...@apple.com wrote: On Jun 6, 2012, at 6:14 PM, Kentaro Hara hara...@chromium.org wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I vaguely recall that I originally implemented rule (b) for WebKit, and at the time I did it because: (1) The exact behavior in this case seemed unimportant; I couldn't find any sites depending on it, nor did it seem likely that they would. (2) It was the simplest apparent way to avoid leaking certain kinds of cycles that span GC and refcounting (I don't remember the details and this is likely no longer applicable)/ (3) It seemed that keeping ancestors alive would have the potential to hold large amounts of memory when much of it was unneeded. An even more extreme example of (3) would result if both parentNode and ownerDocument were strong references, and ownerDocument was made to be a real reference, not a self-only reference (at some point renamed to guardRef). Then keeping a single node that was in an isolated DOM subtree alive would also keep that whole document alive. I am not sure what other browsers do in this case. Of course, predictability might outweigh the potential memory use issues. Regards, Maciej -- 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] Adding nonstandard features (was Re: Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore)
On Jun 7, 2012, at 1:10 PM, Adam Barth aba...@webkit.org wrote: On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org wrote: I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator). This feature will be behind the ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: https://bugs.webkit.org/show_bug.cgi?id=88358 http://html.spec.whatwg.org/#navigator What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? Generally, we avoid implementing web visible features via the chrome object because that makes them Chrome-proprietary. In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well. This thread seems mostly over, but taking the opportunity to make a broader point: If we want to invite other browsers to implement a feature, then we should propose it to the relevant standards group (and prefix it or just don't add it if it seems likely to be rejected). Just implementing unprefixed, without discussing with a relevant standards group first, is not the best approach. It can needlessly damage our relations with other implementors and the relevant standards groups themselves. While browser implementors in general, and the WebKit project in particular, have not always done a great job of this, this, we've been trying to do this more consistently since we adopted a process for reviewing feature additions. [1] We may even want to update that policy page to mention that you'll very likely be asked, is this on the standards track? and if the answer is no you need a particularly compelling reason. Regards, Maciej [1] http://www.webkit.org/coding/adding-features.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding nonstandard features (was Re: Adding ENABLE_NAVIGATOR_BUILDTYPE to WebCore)
On Mon, Jun 11, 2012 at 6:29 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 7, 2012, at 1:10 PM, Adam Barth aba...@webkit.org wrote: On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan sulli...@chromium.org wrote: I wanted to let you know that I plan to add support for navigator.buildType (e.g., nightly, beta, final) to WebKit. This feature isn't on the standards track (but neither are a bunch of other similar properties on Navigator). This feature will be behind the ENABLE(NAVIGATOR_BUILDTYPE) feature define. See: https://bugs.webkit.org/show_bug.cgi?id=88358 http://html.spec.whatwg.org/#navigator What is the rationale for adding this property on the navigator object instead of the chrome object we also expose if your'e not expecting this property to be ever standarized? Generally, we avoid implementing web visible features via the chrome object because that makes them Chrome-proprietary. In this case, it seems entirely reasonable for other browsers (e.g., Firefox) to want to implement this feature. By putting it on navigator, we invite them to implement it as well. This thread seems mostly over, but taking the opportunity to make a broader point: If we want to invite other browsers to implement a feature, then we should propose it to the relevant standards group (and prefix it or just don't add it if it seems likely to be rejected). Just implementing unprefixed, without discussing with a relevant standards group first, is not the best approach. It can needlessly damage our relations with other implementors and the relevant standards groups themselves. While browser implementors in general, and the WebKit project in particular, have not always done a great job of this, this, we've been trying to do this more consistently since we adopted a process for reviewing feature additions. [1] We may even want to update that policy page to mention that you'll very likely be asked, is this on the standards track? and if the answer is no you need a particularly compelling reason. The approach we try to use in the Chromium project is somewhat documented at http://dev.chromium.org/developers/how-tos/make-a-web-standards-proposal. That approach seems to work pretty well for moderate and large features. We've had some trouble with tiny features because the overhead seems a bit too large. (I'd classify navigator.buildType as a tiny feature.) There's somewhat of a chicken-and-egg problem between implementation and standardization. You don't really want either process to get too far ahead of the other. One intermediate step that I've found useful (and I recommended in the how-to) is to write up a proto-specification like http://wiki.whatwg.org/wiki/AllowSeamless. That gives folks something concrete to read and think about without getting stalled on the politics around a FPWD for a new working group. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
I'm the guy that added css3/calc tests. I did so because I not all my tests are 'text only' tests, but I still wanted them all together. My understanding was that the 'fast' directory was intended for 'text only' tests only. Does having the 'fast' directory still serve a useful purpose? I reckon the original intent could be pushed into the tools, eg have a 'new-run-webkit-tests --fast', which will only run text-only tests. Then the developer adding new tests doesn't have to worry about where to put them. mike On 11 June 2012 18:57, Ryosuke Niwa rn...@webkit.org wrote: Hi, I realized that there are a whole bunch of tests in LayoutTests/css3 that use layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to mean that they're our own tests. However, css3/selectors3 is an imported W3C test suite. It's very confusing to mix imported tests and WebKit's own tests. Can we put the imported W3C tests in imported-w3c directory as proposed earlier? 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
On Mon, Jun 11, 2012 at 7:33 PM, Mike Lawther mikelawt...@chromium.orgwrote: I did so because I not all my tests are 'text only' tests, but I still wanted them all together. My understanding was that the 'fast' directory was intended for 'text only' tests only. That's not the case. The reason we have many pixel tests in css1, css2.1, and css3 directories compared to fast is because imported tests tend to be pixel tests whereas we try to create text-only tests. Does having the 'fast' directory still serve a useful purpose? It's a historical artifact at this point as far as I'm concerned. I reckon the original intent could be pushed into the tools, eg have a 'new-run-webkit-tests --fast', which will only run text-only tests. Then the developer adding new tests doesn't have to worry about where to put them. While I agree on the usefulness of --fast option, the slowness of a test doesn't necessarily come from text vs. pixel tests. It depends more on what each test is testing. There are lots of text-only tests that are very slow. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree traversal on detached nodes
Thanks ggaren! I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=88834 I believe you could achieve (a) (i.e., preserve all reachable nodes without help from the JavaScript garbage collector) with these semantics in the C++ DOM: = Design = ref(): ++this-refCount ++root()-refCount deref(): --this-refCount --root()-refCount Actually I've tried the approach yesterday but confirmed 25.9% performance regression, even if I have TreeShared hold a pointer to the root. Please look at the WIP patch and the performance test in https://bugs.webkit.org/show_bug.cgi?id=88834. What I've learned is that we must not insert any line to ref() and deref(), which are performance sensitive:) I am now trying another approach that hacks Node destruction. Let's discuss the implementation details in the bug. Thanks! On Tue, Jun 12, 2012 at 12:18 PM, Geoffrey Garen gga...@apple.com wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I believe you could achieve (a) (i.e., preserve all reachable nodes without help from the JavaScript garbage collector) with these semantics in the C++ DOM: = Design = ref(): ++this-refCount ++root()-refCount deref(): --this-refCount --root()-refCount if !root()-refCount: assert(!this-refCount) for each descendent of root(): delete descendent delete root() Remove 'this' from tree: assert(this-refCount) // clients must put a node into a RefPtr to remove it from a tree root()-refCount -= this-refCount for each descendent of this: this-refCount += descendent-refCount Insert 'this' into tree: root()-refCount += this-refCount for each descendent of this: this-refCount -= descendent-refCount What is root()?: If this is in a document: root() == document() else: root() == the highest link in the parentNode chain = FAQ = Cycles? No cycles are possible because the DOM API does not allow cycles in a DOM tree. Is O(n) subtree insertion and removal OK? I believe these operations are already O(n). Is average case O(log n) access to disconnected root() OK? If n is small and/or ref/deref of disconnected subnodes are rare, then yes. Otherwise, we can optimize this case by putting a direct pointer to root() in rare data. Geoff -- 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
Re: [webkit-dev] DOM tree traversal on detached nodes
IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I believe you could achieve (a) (i.e., preserve all reachable nodes without help from the JavaScript garbage collector) with these semantics in the C++ DOM: = Design = ref(): ++this-refCount ++root()-refCount deref(): --this-refCount --root()-refCount if !root()-refCount: assert(!this-refCount) for each descendent of root(): delete descendent delete root() Remove 'this' from tree: assert(this-refCount) // clients must put a node into a RefPtr to remove it from a tree root()-refCount -= this-refCount for each descendent of this: this-refCount += descendent-refCount Insert 'this' into tree: root()-refCount += this-refCount for each descendent of this: this-refCount -= descendent-refCount What is root()?: If this is in a document: root() == document() else: root() == the highest link in the parentNode chain = FAQ = Cycles? No cycles are possible because the DOM API does not allow cycles in a DOM tree. Is O(n) subtree insertion and removal OK? I believe these operations are already O(n). Is average case O(log n) access to disconnected root() OK? If n is small and/or ref/deref of disconnected subnodes are rare, then yes. Otherwise, we can optimize this case by putting a direct pointer to root() in rare data. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree traversal on detached nodes
Actually I've tried the approach yesterday but confirmed 25.9% performance regression, even if I have TreeShared hold a pointer to the root. Please look at the WIP patch and the performance test in https://bugs.webkit.org/show_bug.cgi?id=88834. What I've learned is that we must not insert any line to ref() and deref(), which are performance sensitive:) I don't take away the same lesson. The WIP patch you posted has these performance issues: - adds 2 data members to every node, increasing malloc cost and memory traffic - adds a call to fprintf inside ref() and deref(), probably making them ineligible for inlining - does a test against !m_parent in rootDeref, which can be removed Also, does your benchmark, with this patch attached, ever tear down a DOM tree? You haven't changed any of the other document tear-down machinery to match, so you're still paying the cost of lots of irrelevant tear-down code, and/or possibly leaking lots of memory. To test your ref is sacred theory on this benchmark, just insert this one line of code into ref(): document()-ref(); This is a memory leak, but it will make it through your benchmark without crashing, and give you a ballpark performance test of the design I described. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM tree traversal on detached nodes
I think that a lot of the performance penalty can be alleviated by: 1) Moving rarely executed paths into non-inlineable methods. 2) Marking the various refing methods ALWAYS_INLINE, after you've moved as much as possible out of line. 3) Using LIKELY and UNLIKELY where appropriate. The reason I suggest these things is that you're adding a lot of code in a bunch of methods, but a lot of that logic looks like it will execute infrequently. That reduces inlining opportunities. And in places where the methods are still inlined, you're adding code bloat that reduces icache locality and may blow out branch prediction caches. I'm also not sure that your benchmark is conclusive. What does the perf test have in common with things we know we care about, like say PLT? -Filip On Jun 11, 2012, at 8:45 PM, Kentaro Hara hara...@chromium.org wrote: Thanks ggaren! I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=88834 I believe you could achieve (a) (i.e., preserve all reachable nodes without help from the JavaScript garbage collector) with these semantics in the C++ DOM: = Design = ref(): ++this-refCount ++root()-refCount deref(): --this-refCount --root()-refCount Actually I've tried the approach yesterday but confirmed 25.9% performance regression, even if I have TreeShared hold a pointer to the root. Please look at the WIP patch and the performance test in https://bugs.webkit.org/show_bug.cgi?id=88834. What I've learned is that we must not insert any line to ref() and deref(), which are performance sensitive:) I am now trying another approach that hacks Node destruction. Let's discuss the implementation details in the bug. Thanks! On Tue, Jun 12, 2012 at 12:18 PM, Geoffrey Garen gga...@apple.com wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I believe you could achieve (a) (i.e., preserve all reachable nodes without help from the JavaScript garbage collector) with these semantics in the C++ DOM: = Design = ref(): ++this-refCount ++root()-refCount deref(): --this-refCount --root()-refCount if !root()-refCount: assert(!this-refCount) for each descendent of root(): delete descendent delete root() Remove 'this' from tree: assert(this-refCount) // clients must put a node into a RefPtr to remove it from a tree root()-refCount -= this-refCount for each descendent of this: this-refCount += descendent-refCount Insert 'this' into tree: root()-refCount += this-refCount for each descendent of this: this-refCount -= descendent-refCount What is root()?: If this is in a document: root() == document() else: root() == the highest link in the parentNode chain = FAQ = Cycles? No cycles are possible because the DOM API does not allow cycles in a DOM tree. Is O(n) subtree insertion and removal OK? I believe these operations are already O(n). Is average case O(log n) access to disconnected root() OK? If n is small and/or ref/deref of disconnected subnodes are rare, then yes. Otherwise, we can optimize this case by putting a direct pointer to root() in rare data. Geoff -- 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
Re: [webkit-dev] DOM tree traversal on detached nodes
Hi ggaren and pizlo Sorry for posting a not-yet-optimized WIP patch. I'll re-post it after optimization you suggested. Also, I described the algorithm I am now implementing. I guess that this algorithm would have less overhead: https://bugs.webkit.org/show_bug.cgi?id=88834#c3 On Tue, Jun 12, 2012 at 1:32 PM, Filip Pizlo fpi...@apple.com wrote: I think that a lot of the performance penalty can be alleviated by: 1) Moving rarely executed paths into non-inlineable methods. 2) Marking the various refing methods ALWAYS_INLINE, after you've moved as much as possible out of line. 3) Using LIKELY and UNLIKELY where appropriate. The reason I suggest these things is that you're adding a lot of code in a bunch of methods, but a lot of that logic looks like it will execute infrequently. That reduces inlining opportunities. And in places where the methods are still inlined, you're adding code bloat that reduces icache locality and may blow out branch prediction caches. I'm also not sure that your benchmark is conclusive. What does the perf test have in common with things we know we care about, like say PLT? -Filip On Jun 11, 2012, at 8:45 PM, Kentaro Hara hara...@chromium.org wrote: Thanks ggaren! I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=88834 I believe you could achieve (a) (i.e., preserve all reachable nodes without help from the JavaScript garbage collector) with these semantics in the C++ DOM: = Design = ref(): ++this-refCount ++root()-refCount deref(): --this-refCount --root()-refCount Actually I've tried the approach yesterday but confirmed 25.9% performance regression, even if I have TreeShared hold a pointer to the root. Please look at the WIP patch and the performance test in https://bugs.webkit.org/show_bug.cgi?id=88834. What I've learned is that we must not insert any line to ref() and deref(), which are performance sensitive:) I am now trying another approach that hacks Node destruction. Let's discuss the implementation details in the bug. Thanks! On Tue, Jun 12, 2012 at 12:18 PM, Geoffrey Garen gga...@apple.com wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I believe you could achieve (a) (i.e., preserve all reachable nodes without help from the JavaScript garbage collector) with these semantics in the C++ DOM: = Design = ref(): ++this-refCount ++root()-refCount deref(): --this-refCount --root()-refCount if !root()-refCount: assert(!this-refCount) for each descendent of root(): delete descendent delete root() Remove 'this' from tree: assert(this-refCount) // clients must put a node into a RefPtr to remove it from a tree root()-refCount -= this-refCount for each descendent of this: this-refCount += descendent-refCount Insert 'this' into tree: root()-refCount += this-refCount for each descendent of this: this-refCount -= descendent-refCount What is root()?: If this is in a document: root() == document() else: root() == the highest link in the parentNode chain = FAQ = Cycles? No cycles are possible because the DOM API does not allow cycles in a DOM tree. Is O(n) subtree insertion and removal OK? I believe these operations are already O(n). Is average case O(log n) access to disconnected root() OK? If n is small and/or ref/deref of disconnected subnodes are rare, then yes. Otherwise, we can optimize this case by putting a direct pointer to root() in rare data. Geoff -- 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 -- 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
Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?
There are plenty of non-text tests in fast/, even entire directories of them (fast/repaint). My understanding of the meaning of fast/ is that it is where new tests that are not imported should go. This meaning is not universally applied. - James On Jun 11, 2012 7:33 PM, Mike Lawther mikelawt...@chromium.org wrote: I'm the guy that added css3/calc tests. I did so because I not all my tests are 'text only' tests, but I still wanted them all together. My understanding was that the 'fast' directory was intended for 'text only' tests only. Does having the 'fast' directory still serve a useful purpose? I reckon the original intent could be pushed into the tools, eg have a 'new-run-webkit-tests --fast', which will only run text-only tests. Then the developer adding new tests doesn't have to worry about where to put them. mike On 11 June 2012 18:57, Ryosuke Niwa rn...@webkit.org wrote: Hi, I realized that there are a whole bunch of tests in LayoutTests/css3 that use layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to mean that they're our own tests. However, css3/selectors3 is an imported W3C test suite. It's very confusing to mix imported tests and WebKit's own tests. Can we put the imported W3C tests in imported-w3c directory as proposed earlier? 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 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
