On Feb 24, 2010, at 3:50 PM, Eric Seidel wrote:
> I find http://build.webkit.org/console more useful.
>
> In this case, looks like mitz's patch changed the test:
> http://trac.webkit.org/changeset/55203
Sorry about the inconvenience. I will try to fix this shortly.
>
> I'm glad to see more fo
What is a possible resolution? Can we temporarily disable the test to
unblock the commit queue?
-Ken
On Wed, Feb 24, 2010 at 3:53 PM, Eric Seidel wrote:
> That test is kinda tricky. The change isn't necessarily wrong. But
> the patch appears to have changed what the DOM tree looks like (at
> l
On Wed, Feb 24, 2010 at 3:48 PM, David Levin wrote:
> 1. It looks like you are a committer, so you don't need to wait for the
> commit queue to do this for you :)
Understood -- but I prefer to use the bots where possible. I've seen
multiple instances where the commit scripts failed to add new fil
That test is kinda tricky. The change isn't necessarily wrong. But
the patch appears to have changed what the DOM tree looks like (at
least in order) and thus exposed bugs in our JS bindings where some
objects aren't being created with the proper prototype chains.
Our JS bindings get cached afte
I find http://build.webkit.org/console more useful.
In this case, looks like mitz's patch changed the test:
http://trac.webkit.org/changeset/55203
I'm glad to see more folks are watching the bots!
-eric
On Wed, Feb 24, 2010 at 3:48 PM, David Levin wrote:
> 1. It looks like you are a committer,
1. It looks like you are a committer, so you don't need to wait for the
commit queue to do this for you :)
2. But it still would be good to have this fixed. If you'd like to help move
this along, you can go to http://build.webkit.org/waterfall and find which
patch caused the test to start failing.
On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov wrote:
>
> On 24.02.2010, at 11:47, David Levin wrote:
>
> Actually, it doesn't appear to be do to recent changes in this area. They
> started failing after r55177
> (http://build.webkit.org/waterfall?last_time=1266975298), but that change is
>
Gustavo,
On Tue, 2010-02-23 at 18:09 -0300, Gustavo Noronha Silva wrote:
> As everyone knows our build system is one of the slowest, so adding
> complexity to it may not be always a good idea.
The changes to the build system should not impact its performance:
checks to choose which files to comp
On 24.02.2010, at 11:47, David Levin wrote:
Actually, it doesn't appear to be do to recent changes in this area.
They started failing after r55177 (http://build.webkit.org/waterfall?last_time=1266975298
), but that change is unrelated to these test as far as I can tell.
It looks unrelated,
Actually, it doesn't appear to be do to recent changes in this area. They
started failing after r55177 (
http://build.webkit.org/waterfall?last_time=1266975298), but that change is
unrelated to these test as far as I can tell.
I suspect it has to do with shuffling around of tests, so it just needs
Adam Barth pointed out that the commit queue has been blocked for
about 20 hours. Looking at the reason why:
editing/undo/undo-deleteWord.html -> failed
editing/undo/undo-iframe-location-change.html -> failed
If you have made changes in this area recently, could you please fix
these test failures
On Feb 23, 2010, at 10:27 PM, Bernhard zwischenbrugger wrote:
> hi all
>
> I'm working on a (openstreetmap) slippy map for iphone browser.
> http://lamp2.fhstp.ac.at/~lbz/beispiele/ws2009/iphonemap4/simple.html
>
> At the moment I have a problem with cancel image loading.
>
> Simple example:
>
Hi Chromium devs,
I noticed in the latest Chromium beta it seemed that there was still no
accessibility for the mac.
It should be a fairly straightforward process of enabling accessibility.
Please contact me if you need any help or guidance in getting the mac
accessibility up and running. We'
13 matches
Mail list logo
