I have a serialized image, which I deserialize from its base64 encoded URL. The encoded URL is correctly serialized and known to work in Browsers and my other SDL-based runtime.
Error and Description
Uncaught InvalidStateError: Failed to execute 'drawImage' on 'CanvasRenderingContext2D': The HTMLImageElement provided is in the 'broken' state.
Steps to reproduce
var img = new Image();
img.src = 'data:image/png;base64,.....'
img.onload = function() {
somecanvas.getContext('2d').drawImage(img); // will fail
};
How can I fix this?
// EDIT: corrected the example to avoid confusions
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
This works for me. Not sure if this matters, but I noticed you have a comma instead of a semi-colon ; between your image type and base64. Also, the drawImage takes 3 arguments.
var img = new Image();
img.onload = function() {
somcanvas.getContext('2d').drawImage(img, 0, 0);
};
img.src = 'data:image/png;base64,iVBORw0KGgoAA....';
I'm using nw 0.10.5
Sorry, updated the example. It was a typo only occuring in the above example. The issue is still occuring.
Is there a way to debug those lock-states of the images? I guess CORS also plays a role for those, but shouldn't be relevant for this example.
I don't know where to start looking for in Chromium's WebAPI, so any hint would be appreciated.
(using nw 0.10.5 on Linux/Ubuntu amd64)
untill nw 0.12.2 on Linux/Unbuntu amd64 this still persists for the given example. Any suggestions on possible walk around ?
I do have the same problem.....
Do you see the same error on Chrome?
Yep, same problem. I want to put a live demo of my JS game on my website. When I play it by itself, it's good, but on the website I get the broken error above. Exact same error.
Same problem here,
Its happening for me on Chrome 47.0.2526.111 m
and InternetExpolorer 11.096
but it is working fine on FireFox 43.0.1
Hey Guys I am also having this error: The HTMLImageElement provided is in the 'broken' state when embedding a view from Tableau Server.
Has anyone found anything on this?
What does it mean?
I think the problem is related to _when_ you draw the image on the canvas. If the image is set via img.src="data url" and the onload callback is fired, the image is _not yet_ really ready for drawing. In my case I had to modify the Image.toString() method in order to avoid the problem and get it integrated with data urls. Note that it's important to lazy load the buffer at least to times in my cases, because the first one will result in above problem.
Might be possible for others to get around the broken state by using setTimeout(draw, 0) inside the img.onload but I really think this is a harsh bug and isn't what the onload API intends to offer.
Thanks
I think I traced down the bug further in upstream Blink:
Related lines:
Somewhere between ImageResource.get() it fails, but I have no effing clue why. They always return pointers in their dummy methods and ImageResource, ImageLoader, Image, HTMLImageElement use all m_image as a property name -_- so I have no effing clue what's going on there.
But maybe this helps nail the bug further down. My partly blind guess is that the ImageLoader for data URLs does not fire the ImageResource::finishOnePart() method or the ImageResource::updateImage(true) soon enough to be directly drawn because that will eventually lead to the ImageObserver not being notified correctly and the onload to be triggered because of the width checks (heights are not checked anywhere, lol).
Maybe you can produce a test case for this by using this and toggle on/off the width/height properties to further trace the bug down the spaghetti code:
let img = new Image();
img.width = 1337;
img.height = 13.37;
img.onload = function() {
context.drawImage(this, 0, 0);
};
img.src = 'data:...';
I can't reproduce this issue on latest stable 0.16.1 or LTS 0.14.7.
I had the same.
In my case, the problem was simply due to too long path to the image file: Seems as if it takes the program longer to find a remote image file than to execute the next command.
By moving the image file to the program folder the problem was solved.
Most helpful comment
I think I traced down the bug further in upstream Blink:
Related lines:
Somewhere between ImageResource.get() it fails, but I have no effing clue why. They always return pointers in their dummy methods and ImageResource, ImageLoader, Image, HTMLImageElement use all
m_imageas a property name -_- so I have no effing clue what's going on there.But maybe this helps nail the bug further down. My partly blind guess is that the ImageLoader for data URLs does not fire the
ImageResource::finishOnePart()method or theImageResource::updateImage(true)soon enough to be directly drawn because that will eventually lead to the ImageObserver not being notified correctly and the onload to be triggered because of the width checks (heights are not checked anywhere, lol).Maybe you can produce a test case for this by using this and toggle on/off the width/height properties to further trace the bug down the spaghetti code: