Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTMLImageElement is in "broken" state. #2470

Closed
cookiengineer opened this issue Oct 16, 2014 · 13 comments
Closed

HTMLImageElement is in "broken" state. #2470

cookiengineer opened this issue Oct 16, 2014 · 13 comments

Comments

@cookiengineer
Copy link

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.

@jwoertink
Copy link

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

@cookiengineer
Copy link
Author

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)

@cyc115
Copy link

cyc115 commented Jul 25, 2015

untill nw 0.12.2 on Linux/Unbuntu amd64 this still persists for the given example. Any suggestions on possible walk around ?

@sebinbenjamin
Copy link

I do have the same problem.....

@ghostoy
Copy link
Member

ghostoy commented Nov 8, 2015

Do you see the same error on Chrome?

@u8y7541
Copy link

u8y7541 commented Dec 21, 2015

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.

@caligoig
Copy link

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

@ProwlElement
Copy link

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?

@cookiengineer
Copy link
Author

cookiengineer commented Aug 25, 2016

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.

@ProwlElement
Copy link

Thanks

@cookiengineer
Copy link
Author

cookiengineer commented Aug 29, 2016

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:...';

@ghostoy
Copy link
Member

ghostoy commented Aug 31, 2016

I can't reproduce this issue on latest stable 0.16.1 or LTS 0.14.7.

@samtal
Copy link

samtal commented Mar 20, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants