drawImage should throw INVALID_STATE_ERR on invalid image, not NS_ERROR_NOT_AVAIL

RESOLVED DUPLICATE of bug 1297211

Status

()

Core
Canvas: 2D
P4
normal
RESOLVED DUPLICATE of bug 1297211
10 years ago
9 months ago

People

(Reporter: Tomcat, Unassigned, NeedInfo)

Tracking

(Depends on: 1 bug)

unspecified
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
Steps to reproduce:

Open the testcase from Bug 391028 and check the error console:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: https://bugzilla.mozilla.org/attachment.cgi?id=275356 :: anonymous :: line 9"  data: no]

reproduced on trunk and 1.8 branch
Flags: blocking1.9?
(Reporter)

Updated

10 years ago
Summary: Testcase from bug cause 391028 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage → Testcase from bug 391028 cause (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage
The testcase is supposed to do that; the png image isn't valid.  The spec says drawImage should throw INVALID_STATE_ERR however.
Flags: blocking1.9? → blocking1.9-
Summary: Testcase from bug 391028 cause (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage → drawImage should throw INVALID_STATE_ERR on invalid image, not NS_ERROR_NOT_AVAIL
Priority: -- → P4
Created attachment 549180 [details]
very simple test case

It's my impression from http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawimage that we should never produce NS_ERROR_NOT_AVAILABLE from drawImage; the only licensed failure modes are INVALID_STATE_ERR, TYPE_MISMATCH_ERR, INDEX_SIZE_ERR, and silently doing nothing.  The test case I'm attaching uses an uninitialized Image object (I presume this is the same as an HTMLImageElement under the hood).  I'm not sure what the *correct* behavior for this test case is; I'm guessing either INVALID_STATE_ERR or silent nop.  However, looking at http://mxr.mozilla.org/mozilla-central/source/content/canvas/src/nsCanvasRenderingContext2D.cpp#3212 I see several places where we return NS_ERROR_NOT_AVAILABLE inappropriately; they should all be audited and corrected (and the analogous code in the Azure reimplementation too).

Updated

6 years ago
Depends on: 691186

Comment 3

5 years ago
I can reproduce this problem with Firefox 16.0.2 on Mac OS X 10.8.2.

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1003380

Comment 5

11 months ago
The fixes for bug 1003380 do not appear to have fixed this bug; if you load the test case attached here, you will see that it still generates NS_ERROR_NOT_AVAILABLE.  Again, as I understand the spec, NS_ERROR_NOT_AVAILABLE should *never* be generated by this API.

(I observe this with 45.2.0ESR/Linux.)
Status: RESOLVED → REOPENED
Flags: needinfo?(cabanier)
Resolution: DUPLICATE → ---

Comment 6

9 months ago
Fixed in bug 1297211. I didn't see this bug when I reported that one.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago9 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1297211
You need to log in before you can comment on or make changes to this bug.