Problem drawing on a canvas on Chrome 57
Reported by
dubald...@gmail.com,
Mar 28 2017
|
||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36
Steps to reproduce the problem:
/* this stuff works on Chrome v56 and lower. */
let tempImage = new Image();
let finalImage = new Image();
image.src = firstCanvas.toDataURL("image/png"); //get image from first canvas
/* here 'image' is absoluterly good */
secondCanvasContext.drawImage(image, 0, 0); //draw the good image on a second canvas
finalImage.src = secondCanvas.toDataURL("image/png"); //get image from second canvas
/* here 'finalImage' is EMPTY */
What is the expected behavior?
What went wrong?
Get the image from 'canvas.toDataURL' and using 'drawingImage' on another canvas produce an empty image.
Did this work before? Yes 56.*
Chrome version: 57.0.2987.110 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
,
Mar 30 2017
I made this jsfiddle to understand the bug: https://jsfiddle.net/ebf08khr/29/ In this examole I draw a shape into the first canvas then I try to get the image ( by .toDataURL ) from the canvas and draw it into a second canvas. This code works for all Chrome versions lower than 57.
,
Mar 31 2017
Able to reproduce the issue on Win 10,Mac 10.12.4 and Ubuntu 14.04 on 57.0.2987.133 and canary 59.0.3056.0. Bisect info: ============== Good: 57.0.2970.0 --441084 Bad : 57.0.2971.0 --441288 You are probably looking for a change made after 441183 (known good), but no later than 441184 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/1aa292f37d0556e36624e9968db50f39a5523a07..b6403174c6111ea0947dc7cf8b1eb8a6f9e8546c Review-Url: https://codereview.chromium.org/2592113003 yoav@:Could you please take a look into this if its related to your change. Added Releaseblock-Stable against M57,and good to have it fixed before next M57 stable push if there is any.
,
Mar 31 2017
UPDATE: Actually img.onload seems to be the solution. As you can see in this new fiddle the code works ! --> https://jsfiddle.net/ebf08khr/37/ BUT...It only works with two canvas, the problem persist when I try to get image from the last canvas and copy the image into another new canvas. Thanks!
,
Mar 31 2017
UPDATE: My problem is solved: https://jsfiddle.net/ebf08khr/108/ Note: multiple img.onload() doesn't works if are in the same function. Thanks to all!.
,
Mar 31 2017
This is not a release blocking bug. There a workaround. It may even be correct behavior according to the spec, given that the blamed change makes image loading asynchronous and the workaround reflects that. On the other hand, it might be that canvas does not have this spec requirement or compatibility issue and we need to special case it somehow.
,
Apr 1 2017
This seems to be WAI. Image loading is now async even if the image is loaded from a dataURI (similar to other browsers). Using onload is the right way to write such functionality, so I wouldn't call it a workaround. Closing as WONTFIX, but please let me know if current behavior differs from other browsers on that front.
,
Apr 11 2017
The async behaviour makes sense as a requirement/expectation, but I am not sure other browsers necessarily follow the async behaviour, certainly Chrome's behaviour has changed between 56 and 57. Current behaviour differs from some other browsers, although it isn't entirely consistent. Take the following code: https://jsfiddle.net/mattonmatter/fqh2p84x/ In IE 11, all three circles have a 3 in them on every load. In Edge 38, all three circles have a 3 in them on every load. In Chrome 56, all three circles have a 3 in them on every load. In Chrome 57, the middle circle is missing a 3 on every load. In Opera 44, the middle circle is missing a 3 on every load. In Firefox 45, the middle circle is missing a 3 on first load, then all three circles have 3 in them on every load (due to caching of data URI). |
||||
►
Sign in to add a comment |
||||
Comment 1 by dtapu...@chromium.org
, Mar 28 2017