fast/canvas/canvas-too-large-to-draw.html failing on El Capitan Debug
@@ -1,2 +1,2 @@
-CONSOLE MESSAGE: line 36: Canvas area exceeds the maximum limit (width * height > 268435456).
+CONSOLE MESSAGE: line 31: TypeError: null is not an object (evaluating 'ctx.fillStyle = "lime"')
Marked as flaky on ElCapitan Debug in r193770
This is related to my change. For some reason, the active pixel count is reaching our maximum threshold while running tests on these machines.
This indicates that either the canvas buffers are getting held onto longer than we expect, or the bookkeeping code is not properly decrementing the counts when run under the test system.
Skipping for now is a good approach, and I'll look into the underlying issue.
Changed expectation to skip in <https://trac.webkit.org/r193794>
Skipped on Win with <https://trac.webkit.org/r193797>
Why not roll out the change until this issue can be addressed? The regression seems pretty bad.
(In reply to comment #5)
> Why not roll out the change until this issue can be addressed? The
> regression seems pretty bad.
I disagree. I think the problem corrected by this patch is far more severe than this test failing.
I'll try to get this test fixed in the next day or two.
(In reply to comment #6)
> (In reply to comment #5)
> > Why not roll out the change until this issue can be addressed? The
> > regression seems pretty bad.
> I disagree. I think the problem corrected by this patch is far more severe
> than this test failing.
> I'll try to get this test fixed in the next day or two.
I just talked with Alexey about the history of the original "canvas-too-large-to-draw" test, and I now agree that it is very important to keep this running.
Therefore, I'll roll my patch out and re-enable this test.
Note that my fix (which made this test flaky) was re-landed:
Revised patch (to satisfy the test case) re-landed:
Committed r194290: <http://trac.webkit.org/changeset/194290>