Bug 15042 - Canvas test toDataURL.png.primarycolours.html fails with high resolution backing store.
Summary: Canvas test toDataURL.png.primarycolours.html fails with high resolution back...
Status: REOPENED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: testsuite (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-02 11:45 UTC by John Knottenbelt
Modified: 2012-10-01 00:55 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Knottenbelt 2011-12-02 11:45:10 UTC
Related to this is https://www.w3.org/Bugs/Public/show_bug.cgi?id=15041 which is a request to clarify the dimensions of the image returned by toDataURL. 

In WebKit, the toDataURL routine returns an image corresponding in dimensions to that of the backing store (device pixels), which can be larger than that of the canvas coordinate space. In this case, the test toDataURL.png.primarycolours.htm fails because the canvas draws the image obtained from toDataURL back onto the canvas without specifying a destination width and height, which defaults to the source image width and height, which is (as explained above) not necessarily the same as the canvas width and height. 

In order to make this test work regardless of the resolution of the backing store, the destination width and height should be provided. 

We should change:

ctx.drawImage(img, 0, 0);

to

ctx.drawImage(img, 0, 0, 100, 50);

Link: http://philip.html5.org/tests/canvas/suite/tests/toDataURL.png.primarycolours.html
Comment 1 kkrueger 2012-03-13 15:18:27 UTC
We are not going to make this change at this time since bug #15041 has not been approved.  Because the bug has not been approved this is a potential change and not a real issue.
Comment 2 James Graham 2012-09-24 20:09:26 UTC
The change to the spec has been made on the whatwg side however and has the support of implementors. Simply refusing to update the test undermines the testing effort because people won't be willing to figure out where the tests are failing because the spec has bureaucracy-related differences from what everyone has actually agreed to implement.

If you think it is a problem to accept this kind of patch we need to fix the repositories to have two branches so that people who are only interested in the W3C copy can selectively ignore test patches corresponding to spec patches that aren't yet applied on the W3C side.