Re: [webkit-dev] Ruby Text Enhancements
On Oct 5, 2010, at 6:25 PM, David Hyatt wrote: On Oct 5, 2010, at 7:33 PM, Eric Mader wrote: On Sep 24, 2010, at 8:02 PM, David Hyatt wrote: This is a tough problem. It seems like you have to get involved in the line layout code e.g., findNextLineBreak in order to really do the right thing. findNextLineBreak uses an iterator that walks the objects, so it's easier to tell what text came before you and what text comes after you. You can also tell whether or not that text will even fit on the line and possibly do the margin hacking there. I just did a prototype that checks for a RenderRubyRun in the isReplaced() code inside findNextLineBreak and calls a method on the RenderRubyRun that takes the last and the next object and sets negative margins by calling setMarginLeft() and setMarginRight(). I stepped through this code and it computes the correct margins, but the margins don't seem to take - the ruby doesn't overlap the surrounding text. Guessing that some other code is resetting the margins, I modified the code to cache the computed margins in the RenderRubyRun object and return the cached values through subclassed marginLeft() and marginRight() methods. With this change, the ruby displays as I would expect. It's probably RenderBlockLineLayout line 348 getting you in trouble (computeInlineDirectionPositionsForLine). computeLogicalWidth is called again, and that will recompute the left/right margins and blow away the changes you made to them. I have no idea why that call is there. It should not be necessary, but maybe there's something subtle I'm missing. You could try removing it, and see if that fixes the problem (it should). Yes, that did the trick! I haven't noticed any obvious problems with that line removed, but I haven't done much testing yet. dave (hy...@apple.com) Regards, Eric___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Build slave: requesting username/password pairs
Hi. I've setup a machine to run as as a build bot for the EFL port. Instructions in the wiki says I should ask for a username/password pair here, so here I am. The necessary configuration to be sent to build.webkit.org was submitted as a patch on bug #47290. On a related note, the EFL EWS is already running. A patch to add the status bubble on Bugzilla has been submitted on bug #47277. Cheers, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build slave: requesting username/password pairs
On Oct 6, 2010, at 12:16 PM, Leandro Pereira wrote: Hi. I've setup a machine to run as as a build bot for the EFL port. Instructions in the wiki says I should ask for a username/password pair here, so here I am. The necessary configuration to be sent to build.webkit.org was submitted as a patch on bug #47290. I'll send you a password after the patch lands. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] On frequently hosing other port's WebKit2 builds
Dear WebKit Community, In the past few weeks there were several occasions where Apple-WebKit2 developers ignored the red Qt EWS on Bugzilla and nonetheless committed their patches and let the Qt bot stay red for several hours without any sign of trying to fix the issues (mostly introduced by thoughtlessness), or asking for help on IRC, or even the webkit-qt mailing list, or CC'ing somebody to the bug who might be able to help fixing the problems before hosing the tree, like with these bugs: https://bugs.webkit.org/show_bug.cgi?id=47281 https://bugs.webkit.org/show_bug.cgi?id=47239 https://bugs.webkit.org/show_bug.cgi?id=47097 https://bugs.webkit.org/show_bug.cgi?id=46585 https://bugs.webkit.org/show_bug.cgi?id=46432 https://bugs.webkit.org/show_bug.cgi?id=46054 https://bugs.webkit.org/show_bug.cgi?id=46043 This is making the lives of the maintainers miserable because if a bot is already red it is completely ignored by other developers, which makes it really hard to catch up. I respectfully think that this kind of arrogant and ignorant way of development does real harm to the community. We have a really fast Qt EWS and the build failures weren't complex ones, the EWS would have only needed a minute more than the style-bot to have a nice output where the errors caused by left-in old API calls or old includes or left-out extra compiler definitions would have shown themselves, and I do not think waiting this few minutes would hurt anyone. Especially because this kind of behaviour is not only disrespectful to us, but also to Eric and Adam who are working hard to make these awsome QA technologies possible. Comments like this https://bugs.webkit.org/show_bug.cgi?id=47097#c10 are really frustrating, because all contributors are supposed to bother with the Mac xcodeproj files and their cryptic hashes, too (not to talk about the other nearly dozen build systems) if they implement something, and stringently have their patches checked on all the EWS. Surpassing all my private disappointment, I think IRC, Bugzilla, the EWS's and other buildbots aren't there to force some kind of an unwanted ritual on developers, in which they only upload patches to Bugzilla to conform some policy, but to make collaboration possible. I do not want my letter to be looked at as an offense or attack, I'd rather like to kindly ask the responsile ones to stop the ignorant and discriminative way of handling other ports, and at least try to show some respect on other developers work. Sorry, if this souded like an offense. WBR, Andras Becsi On behalf of the QtWebKit Team at the University of Szeged ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how to create a test that can perform actions while resources are still loading?
Hi, I am trying to create a layout test that has 2 pages, each containing an iframe. I need to perform the main actions while both iframes are still loading. Does anyone know how I can do this? I've tried opening 2 pages (via window.open) that contain iframes, and performing the actions in the window onload handler for those pages. The iframes may or may not have finished loading when I get to the onload handler. I need something that guarantees both iframes are still loading before I take action. I've also tried making this an http test using a slow loading iframe, but the window onload handler for the page does not run until after its iframe has finished loading. (surprisingly) I'm stuck. Hoping someone on this list can help... Thanks, Jenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to create a test that can perform actions while resources are still loading?
On Oct 6, 2010, at 4:36 PM, Jenn Braithwaite (胡慧鋒) wrote: I've also tried making this an http test using a slow loading iframe, but the window onload handler for the page does not run until after its iframe has finished loading. This seems OK. You can put your test code somewhere other than the load handler. For example, an inline script: script test(); /script That will run right away and won’t wait for the window load event. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. I ask because this adds a developmentRegion = English string to the project file but the older versions of Xcode remove that string. If we all agree to use the newer version, then we can let that string get checked in. If some of us are using the older version it will be frustrating because the string will be removed each time someone edits the project file with an older version and checks it in. If no one objects, we’ll start checking in the project files with developmentRegion in there. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
+1000 for stoping the edit war over developmentRegion = English. Adam On Wed, Oct 6, 2010 at 5:00 PM, Darin Adler da...@apple.com wrote: Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. I ask because this adds a developmentRegion = English string to the project file but the older versions of Xcode remove that string. If we all agree to use the newer version, then we can let that string get checked in. If some of us are using the older version it will be frustrating because the string will be removed each time someone edits the project file with an older version and checks it in. If no one objects, we’ll start checking in the project files with developmentRegion in there. -- Darin ___ 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] setTimeout and Safari
Hoping someone on -dev might have an idea about this... -Steve -- Forwarded message -- From: Steve Conover scono...@gmail.com Date: Tue, Sep 28, 2010 at 11:19 PM Subject: Re: setTimeout and Safari To: webkit-h...@lists.webkit.org Actually I am discovering what one might describe as a normal problem here...how to know when the setTimeout's are done firing. The ideal would that I could somehow drill into the dom implementation and ask whether any setTimeout events are waiting to fire (and stop polling if the queue length is zero). I'm sure that's way off in terms of how this is actually implemented. Does such a thing exist? Could someone please point me to the relevant sourcecode? Regards, Steve On Tue, Sep 28, 2010 at 10:36 PM, Steve Conover scono...@gmail.com wrote: Sigh. Please disregard. After an hour of troubleshooting, I sent this email, and two minutes later realized the problem was bad js (blush). On Tue, Sep 28, 2010 at 10:22 PM, Steve Conover scono...@gmail.com wrote: I hope this is the right place to be asking this question. I'm using the cocoa api, and am able to load a web page in a WebView. However I have some javascript in the page that uses setTimeout to cause a function to fire 100ms into the future - but the page loads and ignores the setTimeout's. How do I get my setTimeout's to fire? I suspect this has something to do with the Run Loop, but my experiments so far with various parts of the Run Loop api have been failures. Regards, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout and Safari
Why do you need to know if there are no more pending setTimeouts? Simon On Oct 6, 2010, at 5:52 PM, Steve Conover wrote: Hoping someone on -dev might have an idea about this... -Steve -- Forwarded message -- From: Steve Conover scono...@gmail.com Date: Tue, Sep 28, 2010 at 11:19 PM Subject: Re: setTimeout and Safari To: webkit-h...@lists.webkit.org Actually I am discovering what one might describe as a normal problem here...how to know when the setTimeout's are done firing. The ideal would that I could somehow drill into the dom implementation and ask whether any setTimeout events are waiting to fire (and stop polling if the queue length is zero). I'm sure that's way off in terms of how this is actually implemented. Does such a thing exist? Could someone please point me to the relevant sourcecode? Regards, Steve On Tue, Sep 28, 2010 at 10:36 PM, Steve Conover scono...@gmail.com wrote: Sigh. Please disregard. After an hour of troubleshooting, I sent this email, and two minutes later realized the problem was bad js (blush). On Tue, Sep 28, 2010 at 10:22 PM, Steve Conover scono...@gmail.com wrote: I hope this is the right place to be asking this question. I'm using the cocoa api, and am able to load a web page in a WebView. However I have some javascript in the page that uses setTimeout to cause a function to fire 100ms into the future - but the page loads and ignores the setTimeout's. How do I get my setTimeout's to fire? I suspect this has something to do with the Run Loop, but my experiments so far with various parts of the Run Loop api have been failures. Regards, Steve ___ 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] intercept all http requests, best way to run headless webkit
Another couple of questions - hoping people on webkit-dev might be able to help. -Steve -- Forwarded message -- From: Steve Conover scono...@gmail.com Date: Tue, Sep 28, 2010 at 7:53 AM Subject: intercept all http requests, best way to run headless webkit To: webkit-h...@lists.webkit.org Hi, 1. I'm using the WebKit cocoa api and would like to intercept all http traffic. So, let's say a request is generated by a user action, whether it's a GET, POST, Ajax GET, etc - I'd like to intercept the http request, inspect it and do some work, and then return an http response object that I've created, without the browser attempting to do any further processing of the request (e.g. going out to the internet). What are my options, given my environment? What would you recommend I do? 2. A more general question: what's the best way to construct a headless webkit browser these days? As I mentioned I'm using cocoa, I've constructed a rudimentary headless Safari browser: http://github.com/sconover/schnauzer/blob/master/lib/schnauzer.rb I'm content to be tied to OSX, but obviously a cross-platform solution would be preferable if that's doable/not too onerous. What are people doing these days to create embedded/server-side webkit instances? Regards, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
+1 +1 +1 ! On Oct 6, 2010, at 5:00 PM, Darin Adler wrote: Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. I ask because this adds a developmentRegion = English string to the project file but the older versions of Xcode remove that string. If we all agree to use the newer version, then we can let that string get checked in. If some of us are using the older version it will be frustrating because the string will be removed each time someone edits the project file with an older version and checks it in. If no one objects, we’ll start checking in the project files with developmentRegion in there. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] a ping landed
We've never really formalized an approach to new Web platform features, but the usual practice has been something like: - Use an ENABLE macro if the feature is one that ports may be unable to support immediately or may wish to turn off for other reasons. - Have it on by default if: (a) The feature is part of a standard or clearly standards-track; or the WebKit community has rough consensus that it is a worthwhile feature for the project to support (b) And it is stable enough that having it on wouldn't make trunk unusable for testing. - For features where there is not consensus on the appropriateness and usefulness, we make some effort to come to consensus, though full agreement isn't always possible. - Sometimes things get fuzzier than that and there may be special circumstances. - It's reasonably common for features to start out off by default, for a variety of reasons, and then get turned on by default later. Applying specifically to this case, a ping seems to be a worthwhile feature, and there seems to be good reason to believe the code is stable. However, there is a special circumstance, i.e. the negative public reaction it has elicited at times in the past. In the past, and most likely in the future, most WebKit additions to the Web platform have been greeted in a largely positive way, so this is an unusual situation, and I do not expect it to come up very often. To be more specific: some have perceived this feature as being anti-privacy, and privacy on the Web has been a topic of significant public attention. This stance may not be entirely fair, since the alternative to a ping is not a world where no one tracks outgoing links; rather, it is a world where sites do so in a way that hurts performance and is significantly more difficult for users to avoid. But that is a tricky case to make, and perhaps some will not be convinced until they see the future in action. To be clear, the aim here is not to slow down adoption of a ping but rather to give vendors and port maintainers the choice of whether to take on some PR risk by being one of the early adopters of this feature, as a courtesy. I think it is likely that in time, this risk will blow over. Regards, Maciej On Oct 5, 2010, at 2:45 AM, Dirk Pranke wrote: Fair enough; in retrospect I realize my message may have come across with the wrong tone. Mostly I was just wondering how often we do this, since it doesn't seem like you'd want this to be the blanket approach to new things. I defer to Maciej's (and others') wisdom as to what the right thing to do is on this particular feature. -- Dirk On Mon, Oct 4, 2010 at 11:25 PM, Darin Fisher da...@chromium.org wrote: I don't think it is the norm. This one is special for the reasons already stated. -Darin On Mon, Oct 4, 2010 at 11:17 PM, Dirk Pranke dpra...@chromium.org wrote: Keeping it off by default until it has some mainstream acceptance seems like a bit of a self-defeating policy for new features; is this often done in WebKit? -- Dirk On Mon, Oct 4, 2010 at 10:12 PM, Maciej Stachowiak m...@apple.com wrote: Since a ping has been controversial in the past (for arguably bogus reasons, but controversial nontheless), I suggest we keep it off by default until we find it has some mainstream acceptance and/or we discover that more ports want it. Regards, Maciej P.S. We haven't decided yet if we want it on for the ports Apple ships, but it's probable we will turn it on sooner or later. On Oct 4, 2010, at 6:51 PM, Jeremy Orlow wrote: Given that a ping really doesn't open up any new privacy holes (just makes it easier for sites to get the data they're going to gather anyway without slowing down the experience for the user), it seems like we might as well enable it by default. If a port doesn't want it, they can always disable it, right? Thanks, J On Fri, Oct 1, 2010 at 12:39 PM, Nate Chapin jap...@chromium.org wrote: This is a few days late, but I just wanted to let the team know that, as of http://trac.webkit.org/changeset/68166, WebKit can support a ping (but support is disabled by default). The reason I left it disabled by default is that some ports may want to have a mechanism for disabling pings, and I didn't want anyone to accidentally pick it up before they were ready. I'm happy to flip it to enabled by default if that's what people prefer. ~Nate ___ 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
Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
Can we go one better and also update Visual Studio? :-) On Oct 6, 2010, at 5:55 PM, Chris Marrin wrote: +1 +1 +1 ! On Oct 6, 2010, at 5:00 PM, Darin Adler wrote: Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Upgrading VS (WAS: Any objections to switching to Xcode 3.2.4 or newer?)
Although this is a noble goal, wouldn't it require either 1) Us maintaining yet another build system or 2) Any Windows based WebKit hackers needing to upgrade their Visual Studio...which would require $$? [1] Either way, what's our migration plan (since we can't use VS 2005 forever)? J [1] Yes xcode does require a mac, and that's not free, but anyone already using a particular version of xcode should be able to upgrade, right? On Wed, Oct 6, 2010 at 8:08 PM, Brent Fulgham bfulg...@gmail.com wrote: Can we go one better and also update Visual Studio? :-) On Oct 6, 2010, at 5:55 PM, Chris Marrin wrote: +1 +1 +1 ! On Oct 6, 2010, at 5:00 PM, Darin Adler wrote: Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. ___ 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] On frequently hosing other port's WebKit2 builds
Maybe making EWS bots build already r+'ed patches could help here as well. On Wed, Oct 6, 2010 at 7:13 PM, Andras Becsi abe...@inf.u-szeged.hu wrote: Dear WebKit Community, In the past few weeks there were several occasions where Apple-WebKit2 developers ignored the red Qt EWS on Bugzilla and nonetheless committed their patches and let the Qt bot stay red for several hours without any sign of trying to fix the issues (mostly introduced by thoughtlessness), or asking for help on IRC, or even the webkit-qt mailing list, or CC'ing somebody to the bug who might be able to help fixing the problems before hosing the tree, like with these bugs: https://bugs.webkit.org/show_bug.cgi?id=47281 https://bugs.webkit.org/show_bug.cgi?id=47239 https://bugs.webkit.org/show_bug.cgi?id=47097 https://bugs.webkit.org/show_bug.cgi?id=46585 https://bugs.webkit.org/show_bug.cgi?id=46432 https://bugs.webkit.org/show_bug.cgi?id=46054 https://bugs.webkit.org/show_bug.cgi?id=46043 This is making the lives of the maintainers miserable because if a bot is already red it is completely ignored by other developers, which makes it really hard to catch up. I respectfully think that this kind of arrogant and ignorant way of development does real harm to the community. We have a really fast Qt EWS and the build failures weren't complex ones, the EWS would have only needed a minute more than the style-bot to have a nice output where the errors caused by left-in old API calls or old includes or left-out extra compiler definitions would have shown themselves, and I do not think waiting this few minutes would hurt anyone. Especially because this kind of behaviour is not only disrespectful to us, but also to Eric and Adam who are working hard to make these awsome QA technologies possible. Comments like this https://bugs.webkit.org/show_bug.cgi?id=47097#c10 are really frustrating, because all contributors are supposed to bother with the Mac xcodeproj files and their cryptic hashes, too (not to talk about the other nearly dozen build systems) if they implement something, and stringently have their patches checked on all the EWS. Surpassing all my private disappointment, I think IRC, Bugzilla, the EWS's and other buildbots aren't there to force some kind of an unwanted ritual on developers, in which they only upload patches to Bugzilla to conform some policy, but to make collaboration possible. I do not want my letter to be looked at as an offense or attack, I'd rather like to kindly ask the responsile ones to stop the ignorant and discriminative way of handling other ports, and at least try to show some respect on other developers work. Sorry, if this souded like an offense. WBR, Andras Becsi On behalf of the QtWebKit Team at the University of Szeged ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Upgrading VS (WAS: Any objections to switching to Xcode 3.2.4 or newer?)
On Oct 6, 2010, at 5:13 PM, Jeremy Orlow wrote: 2) Any Windows based WebKit hackers needing to upgrade their Visual Studio...which would require $$? [1] Could we use the Visual Studio Express Editions? They're free. Regards, Eric___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Rich Text Editing Test suite
Hi Ryosuke, looking closer at RTE2-AC_JF_TEXT-1_SC it seems to actually pass on my Chrome Mac build (but it doesn't generate a br)?!): Result: div style=text-align: justifyfoo^bar/div Chromium7.0.547.0 (Developer Build ) WebKit534.10 V82.4.8 did you make any changes, or are you looking at a different build? Cheers, - Roland On Fri, Oct 1, 2010 at 8:07 PM, Ryosuke Niwa rn...@webkit.org wrote: However, we pass JustifyLeft, JustifyRight, JustifyCenter even though we also add BR in those cases. I don't quite understand the difference there... - Ryosuke On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner rolandstei...@google.comwrote: On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa rn...@webkit.org wrote: Mn... I realized something strange here. RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on foo^bar. However, it clearly works on WebKit when I test it manually. It generates div style=text-align: justify;foobarbr/div. I'm not sure why the test claims that WebKit fails on this particular test. That is probably one of the areas that needs discussion - the way the suite is set up currently, it doesn't allow for superfluous HTML elements. I.e., my guess is that it fails because of the extra br (ATM I don't have a TOT WebKit browser, so can't confirm for sure). I have added cases like this as acceptable (but not ideal) results for some tests, but not yet all of them (if we want to add this, then I guess I should implement some systematic way to check these rather than adding it by hand, though). Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On frequently hosing other port's WebKit2 builds
On Wed, Oct 6, 2010 at 9:33 PM, Antonio Gomes toniki...@gmail.com wrote: Maybe making EWS bots build already r+'ed patches could help here as well. That's a top feature request. I'll make that happen next time I get some time to work on the tools. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
