If we have + buttons for all the failures, might as well have them for
the http logs too. :p
On Tue, May 3, 2011 at 2:23 PM, Eric Seidel wrote:
> IIRC the "showing wdiff when there is no wdiff" bug has since been
> fixed? (but that bot just hasn't updated?)
>
> what's the "failure type" column? (
IIRC the "showing wdiff when there is no wdiff" bug has since been
fixed? (but that bot just hasn't updated?)
what's the "failure type" column? (and why can't I select its text?)
Why do expected flaky tests show up in the "Expected to fail but passed" list?
Seems expected flaky tests should be i
Here is a link to the NRWT bot running the Mac Leopard Release build:
http://build.webkit.org/results/Leopard%20Intel%20Release%20(NRWT)/r85644%20(142)/results.html
-- Dirk
On Tue, May 3, 2011 at 2:14 PM, Eric Seidel wrote:
> Is that a good example? It doesn't remind me much of the ORWT output
Is that a good example? It doesn't remind me much of the ORWT output.
The disclosure triangles don't seem to do anything for hte failures on
that page.
On Tue, May 3, 2011 at 2:05 PM, Ojan Vafai wrote:
> On Tue, May 3, 2011 at 1:44 PM, Adam Roben wrote:
>>
>> On May 3, 2011, at 4:01 PM, Ojan V
On Tue, May 3, 2011 at 1:44 PM, Adam Roben wrote:
> On May 3, 2011, at 4:01 PM, Ojan Vafai wrote:
>
> The results load considerably faster now. For runs where many tests fail,
> the filesize is considerably smaller than the
> old-run-webkit-tests filesize. Also, I've added in the image toggling
>
On May 3, 2011, at 4:01 PM, Ojan Vafai wrote:
> The results load considerably faster now. For runs where many tests fail, the
> filesize is considerably smaller than the old-run-webkit-tests filesize.
> Also, I've added in the image toggling behavior of old-run-webkit-tests and
> made the aesth
The results load considerably faster now. For runs where many tests fail,
the filesize is considerably smaller than the old-run-webkit-tests
filesize. Also,
I've added in the image toggling behavior of old-run-webkit-tests and made
the aesthetics a bit closer to the old-run-webkit-test format.
Som
> I was referring mostly to build-webkit ifs, assuming that the #ifdefs
> in the cpp code were still around as well. But it's possible those
> already got removed. :)
I think Eric's question is broader than just #ifdefs. Bugzilla has
some Tiger bugs that we should close if we consider Tiger's sup
I was referring mostly to build-webkit ifs, assuming that the #ifdefs
in the cpp code were still around as well. But it's possible those
already got removed. :)
-eric
On Tue, May 3, 2011 at 11:07 AM, Mark Rowe wrote:
>
> On 2011-05-03, at 10:58, Eric Seidel wrote:
>
>> It looks like Tiger suppo
On 2011-05-03, at 10:58, Eric Seidel wrote:
> It looks like Tiger support in WebKit is slowly being removed. There
> no longer is a libWebKitSystemInterfaceTiger.a in the project, nor is
> there a Tiger buildbot or tiger expectations.
>
> Can we go ahead and kill all the ifdefs too? Or is it t
It looks like Tiger support in WebKit is slowly being removed. There
no longer is a libWebKitSystemInterfaceTiger.a in the project, nor is
there a Tiger buildbot or tiger expectations.
Can we go ahead and kill all the ifdefs too? Or is it too early to
call Tiger dead?
-eric
On Mon, May 2, 2011 at 9:39 PM, wrote:
> So, I am facing a roadblock now.
> Is there any other way to run those layout tests on wekbkit2-gtk ??
> Can I use the available patch in the above listed bug report ??
While waiting for my patch to finish the review process, feel free to
apply it and try
On Tue, May 3, 2011 at 1:22 AM, Won J Jeon wrote:
> Thanks for the update. BTW, is there any switch that I need to turn on in
> order to enable WebGL support with QT port?
>
> I built the code by using '--3d-canvas --3d-rendering' switches and
> launched QtTestBrowser by using 'run-launcher'.
> H
13 matches
Mail list logo
