New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Nov 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue 651572

Sign in to add a comment

Issue 651741: 6 failing web-platform-tests for 2d canvas that pass in Firefox and Edge

Reported by, Sep 30 2016 Project Member

Issue description

Comment 1 by, Sep 30 2016

See  issue 651572  for the source of this data, which includes failing subtests.

Comment 2 by, Sep 30 2016

Status: Available (was: Unconfirmed)
Will check these against specs first. Thanks for the report.

Comment 3 by, Sep 30 2016

Some initial investigation:

Chrome follows the specs on these two tests:

The link for the spec is here:

More specifically, 2d.drawImage.zerocanvas.html falls into step 1, which says "returns bad, then abort these steps without drawing anything", so no exception should be thrown.

2d.drawImage.zerosource.html falls  into step 3, "If one of the sw or sh arguments is zero, abort these steps. Nothing is painted.", so no exception should be thrown.

In both cases, chrome does not throw exception.

Comment 4 by, Sep 30 2016

It looks like Safari also passes those tests.

Does it matter at all to web developers what the behavior is here? If it's minor, I'd suggest filing a bug at to make the spec match the test and Edge/Gecko/WebKit.

Comment 5 by, Sep 30 2016

Good point, if all other browser are breaking the specs, then maybe we should change the spec to match the behavior that majority browsers follow. Will have a discussion with junov@.

Comment 6 by, Sep 30 2016

I disagree.  The preferred behavior for canvas APIs has always been to silently fail except in cases of blatant misuse of the API.  In particular we want to avoid throwing exceptions under conditions that could be the result of a non-deterministic behavior (like a network error, or a resource load race).  I speculate that other implementations may be behaving the way they do simply because of this incorrect test.  Going from throwing to non-throwing won't break anything, but the opposite could (uncaught exceptions will halt script execution).

Comment 8 by, Sep 30 2016

#6, maybe a web-platform-tests PR to change the test, inviting comments from those who would then come to fail it, would be a good path forward?

Comment 9 by, Nov 29 2016

Pull request is here:

Comment 10 by, Nov 30 2016

Status: Fixed (was: Available)

Sign in to add a comment