[webkit-dev] C++ unit tests for WebKit?
Bear Travis, Alexandru Chiculita, and I have been working on the WebKit CSS Exclusions implementation. I've been working on a set of C++ classes that are used to compute the layout of inline content around or within exclusion shapes. When I got started, before attempting to integrate the code with WebKit, I wrote a pile of unit tests. This was helpful for the usual reasons but there doesn't appear to be a place for low level unit tests in WebKit. Naturally what I've done will be tested in terms of the Exclusions public JavaScript and CSS APIs, so adding lower level unit tests will not drastically change our confidence about the overall feature working correctly. On the other hand, unit tests can be useful for isolating problems and for implicitly specifying interface semantics that wouldn't otherwise be documented. Have the merits of C++ unit tests been debated before? I noticed that a bug representing as much has been around since 2008 (https://bugs.webkit.org/show_bug.cgi?id=21010). The last comment (2009) concludes with: I'd be interested to hear other's thoughts. Personally, I'd like to be able to include unit tests with worthy C++ classes, however I would also like to hear other's thoughts. Thanks, - Hans ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] C++ unit tests for WebKit?
It looks like Tools/TestWebKitAPI/Tests/WebCore just contains one small KURL test. I could certainly add more for the Exclusions shape classes, but I got that feeling that maybe you get about being the first to take a table at an empty restaurant. Perhaps it's just that most of the C++ classes in WebCore are too interdependent to merit unit testing? - Hans On 7/11/12 2:26 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jul 11, 2012 at 2:23 PM, Hans Muller hmul...@adobe.com wrote: Have the merits of C++ unit tests been debated before? I noticed that a bug representing as much has been around since 2008 (https://bugs.webkit.org/show_bug.cgi?id=21010). The last comment (2009) concludes with: I'd be interested to hear other's thoughts. Personally, I'd like to be able to include unit tests with worthy C++ classes, however I would also like to hear other's thoughts. That has been discussed before. We have some C++ tests, see Tools/TestWebKitAPI/Tests/ You can probably integrate yours in there. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] C++ unit tests for WebKit?
Thanks for the thoughtful reply. It was exactly the community's conventions and customs that I was trying to get a handle on. Not to put too fine a point on it, but I assume that adding unit tests to TestWebKitAPI or writing tests that depend on APIs defined in Internals.idl wouldn't be customary or conventional?I'd been thinking about doing the latter (Internals.idl), just because it would enable testing some low level classes before everything we're working on had been integrated top to bottom. Doing so could just be a private temporary change, since eventually it will be possible to exercise the code via public APIs. - Hans From: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org To: Hans Muller hmul...@adobe.commailto:hmul...@adobe.com Cc: Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org, Konrad Piascik kpias...@rim.commailto:kpias...@rim.com, webkit-dev webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] C++ unit tests for WebKit? Generally speaking, WebKit's testing philosophy is to test at API boundaries, typically either a given port's WebKit API or the web platform API. The benefit of that approach is that it makes it easier for us to refactor the internals of WebCore without being constrained by fragile tests---only by API commitments. In the case of CSS Exclusions, it's likely valuable to think about how you can test the feature via the web platform. Developing a rich set of tests that use web platform APIs has a number of follow-on benefits that WebCore-internal testing doesn't, such as the ability to run the tests in other browsers and to contribute them to the W3C as part of the standards process. Of course, this sort of one-size-fits-all testing strategy works well in come cases in less well in others. I understand that other projects have different testing strategies that have worked well for them, but I would encourage you to try our the community's conventions and customs for a while to get a feel for which ones work well and which ones ought to be improved. Adam On Wed, Jul 11, 2012 at 3:44 PM, Hans Muller hmul...@adobe.commailto:hmul...@adobe.com wrote: It looks like Tools/TestWebKitAPI/Tests/WebCore just contains one small KURL test. I could certainly add more for the Exclusions shape classes, but I got that feeling that maybe you get about being the first to take a table at an empty restaurant. Perhaps it's just that most of the C++ classes in WebCore are too interdependent to merit unit testing? - Hans On 7/11/12 2:26 PM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org wrote: On Wed, Jul 11, 2012 at 2:23 PM, Hans Muller hmul...@adobe.commailto:hmul...@adobe.com wrote: Have the merits of C++ unit tests been debated before? I noticed that a bug representing as much has been around since 2008 (https://bugs.webkit.org/show_bug.cgi?id=21010). The last comment (2009) concludes with: I'd be interested to hear other's thoughts. Personally, I'd like to be able to include unit tests with worthy C++ classes, however I would also like to hear other's thoughts. That has been discussed before. We have some C++ tests, see Tools/TestWebKitAPI/Tests/ You can probably integrate yours in there. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] -webkit-transform-origin-x,y CSS properties
Are the -webkit-transform-origin-x,y CSS properties on their way in our
out? The ugly little test below demonstrates that they're probably not
supported by Opera or Mozilla.
CSSComputedStyleDeclaration::getPropertyCSSValue() in WebKit (explicitly)
ignores them. Should they stay or should they go? Or perhaps they
should just be left alone?
Thanks,
- Hans
html
style
div.square {
position: absolute;
top: 150px;
left: 150px;
width: 100px;
height: 100px;
background-color: blue;
-webkit-transform-origin-x: -150px;
-webkit-transform-origin-y: -150px;
-webkit-transition: -webkit-transform 0.5s;
-moz-transform-origin-x: -150px;
-moz-transform-origin-y: -150px;
-moz-transition: -moz-transform 0.5s;
-o-transform-origin-x: -150px;
-o-transform-origin-y: -150px;
-o-transition: -o-transform 0.5s;
}
div.square:hover {
-webkit-transform: rotate(45deg);
-webki-transition: -webkit-transform 0.5s;
-moz-transform: rotate(45deg);
-moz-transition: -moz-transform 0.5s;
-o-transform: rotate(45deg);
-o-transition: -o-transform 0.5s;
}
/style
body
div class=square/div
/body
/html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ProgressEvents for Images
There's a brief discussion of the cross-origin case in the ProgressEvents for Images WhatWG thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-January/034362.htm l and the WebKit bug about this proposed feature: https://bugs.webkit.org/show_bug.cgi?id=76102 For cross-site images for which crossOrigin is not set, we'd proposed normalizing the loaded and size ProgressEvent attributes: ProgressEvents for cross-origin images should not reveal the actual resource size per http://www.w3.org/TR/progress-events/#security-considerations. This could be avoided by dispatching ProgressEvents with lengthComputable=false (and loaded=0, total=0) for cross-origin images. Alternatively we could dispatch a subclass of ProgressEvent with normalized total and loaded attributes. A normalized image ProgressEvent wouldn't expose the actual size of the resource being downloaded but it would still enable developers to observe relative progress. Normalization would set total to a constant like 1000, and loaded to a relatively correct value. The motivation for providing progress events in the cross origin case is applicaitons like image galleries, that just display a list of image URLs. Displaying (possibly normalized) download progress for images that will be displayed seems desirable. - Hans On 1/23/12 3:42 PM, Charles Pritchard ch...@jumis.com wrote: On 1/23/12 2:55 PM, Dean Jackson wrote: On 17/01/2012, at 10:41 AM, Bear Travis wrote: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. I think this would be extremely useful. It would require a proposal to W3C or WHATWG though. Seems like this would need to follow CORS. Even disclosing the file size is going too far for cross-domain without CORS. -Charles ___ 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
