Canvas.drawImage throws exception if image isn't loaded

RESOLVED FIXED in mozilla2.0b1

Status

()

RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: davidj, Assigned: bzbarsky)

Tracking

unspecified
mozilla2.0b1
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

If you call Canvas.drawImage and the image hasn't loaded, Firefox throws an NS_ERROR_NOT_AVAILABLE error. According to the docs it should halt the script until the image has loaded.

Reproducible: Always

Steps to Reproduce:
1. var img = new Image()
2. img.src = ...
3. ctx.drawimage(img, 0, 0);

(make sure you shift+reload the page, so that it has to reload the image).
Actual Results:  
Should draw the image.

Expected Results:  
Returns this error:
uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: http://dev.groupboard.com/drawimage.html :: draw
(In reply to comment #0)
> If you call Canvas.drawImage and the image hasn't loaded, Firefox throws an
> NS_ERROR_NOT_AVAILABLE error. According to the docs it should halt the script
> until the image has loaded.

That's not correct; the spec states:

> If the image argument is an HTMLImageElement  object whose complete  attribute is false, or if the image argument is an HTMLVideoElement  object whose readyState  attribute is either HAVE_NOTHING  or HAVE_METADATA, then the implementation must return without drawing anything.

Our implementation was done before that was added to the spec; so the only change here would be that we should just not throw an exception.  But script execution won't ever block until the image is loaded.
(Reporter)

Comment 2

9 years ago
The developer documentation states:

>If loading isn't finished when a drawImage statement gets executed, the script halts until the image is finished loading.

Perhaps the developer documentation is just wrong and needs updated.
(Assignee)

Comment 3

9 years ago
Confirming this; this recently came up on the whatwg mailing list too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 4

9 years ago
Created attachment 450656 [details] [diff] [review]
Possible patch

Though note comments for image elements.  I can add another QI to do what the spec says for HTMLImageElement if we want to be safe...  But I'd rather see what the response is to my suggesting that other images be usable here and how the spec changes as a result.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #450656 - Flags: review?(vladimir)
(Assignee)

Comment 5

9 years ago
Created attachment 450658 [details] [diff] [review]
And actually including the test
Attachment #450656 - Attachment is obsolete: true
Attachment #450658 - Flags: review?(vladimir)
Attachment #450656 - Flags: review?(vladimir)
Comment on attachment 450658 [details] [diff] [review]
And actually including the test

Looks good to me; what other images are you referring to?  Video etc?
Attachment #450658 - Flags: review?(vladimir) → review+
(Assignee)

Comment 7

9 years ago
> what other images are you referring to?

<input type="image">, <object src="some image">, <svg:image>.
(Assignee)

Comment 8

9 years ago
Pushed http://hg.mozilla.org/mozilla-central/rev/391f93244331
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
(Reporter)

Comment 9

8 years ago
Boris, you might want to have a look at bug 574330 - I think your fix for this bug might have caused another bug.
It couldn't have, since all the comments in bug 574330 are about 1.9.2, and this change was made only on 2.0.
You need to log in before you can comment on or make changes to this bug.