Re: [whatwg] A question about the drawimage() canvas function

This behavior seems to match the spec [1] except for step 2:

If the image argument is an HTMLCanvasElement object with either a
horizontal dimension or a vertical dimension equal to zero, then the
implementation throw an InvalidStateError exception and return aborted.


I think that should be:

If the image argument is a  *CanvasImageSource *object with either a
horizontal dimension or a vertical dimension equal to zero, then the
implementation throw an InvalidStateError exception and return aborted.

The non-normative section in drawImage [2] also has this:

If the image has no image data, throws an InvalidStateError exception. If
the image isn't yet fully decoded, then nothing is drawn.

which seems to suggest this too.

This is a bug in WebKit that should be fixed. Can you log a bug with a test
case?

1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#check-the-usability-of-the-image-argument
2:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawimage

On Fri, Mar 1, 2013 at 7:48 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Mar 1, 2013 at 7:49 AM, Kang-Hao (Kenny) Lu <kanghaol@oupeng.com
> >wrote:
>
> >  The spec currently says
> >
> >   # 1. If the image argument is an HTMLImageElement object that is not
> >   #    fully decodable, or if the image argument is an HTMLVideoElement
> >   #    object whose readyState attribute is either HAVE_NOTHING or
> >   #    HAVE_METADATA, then return bad and abort these steps.
> >
> > An <img> without @src isn't fully decodable by definition and therefore
> > no exception should be thrown.
> >
> > However, I worry that WebKit would not be willing to change this to to
> > reflect the spec as I think this behavior has been existing for a long
> > time (correct me if I am wrong here). Firefox has a bug for this[1] but
> > I can't find one in WebKit yet.
> >
>
> To be specific, testing WebKit (in Chrome 24) and Firefox 19 (
> https://zewt.org/~glenn/test-drawimage-exception.html):
>
> - In Chrome, drawImage(img, dx, dy) before the image is downloaded does
> nothing.
> - In Chrome, drawImage(img, dx, dy, dw, dh) before the image is downloaded
> does nothing.
> - In Chrome, drawImage(img, dx, dy) after the image fails to download does
> nothing.
> - In Chrome, drawImage(img, dx, dy, dw, dh) after the image fails to
> download throws an exception.
>
> - In Firefox, drawImage(img, dx, dy) before the image is downloaded does
> nothing.
> - In Firefox, drawImage(img, dx, dy, dw, dh) before the image is downloaded
> does nothing.
> - In Firefox, drawImage(img, dx, dy) after the image fails to download
> throws an exception.
> - In Firefox, drawImage(img, dx, dy, dw, dh) after the image fails to
> download throws an exception.
>
> IE9 matches Firefox.
>
> It looks like the pattern is to not throw an exception for drawing before
> the image finishes loading, but to throw an exception if the image fetch
> did complete, but failed.  Chrome in the 3rd case above seems like the
> exception.
>
> I imagine one of the Chrome cases is a bug, since it doesn't make sense
> that the three-argument and five-argument versions have different behavior.
>  (I really hope that's just a bug, and not weird web-compat.)  I think the
> spec should also reflect what browsers are converging on: throw an
> exception if the image is in the "broken" state, but not in "unavailable"
> or "partially available".
>
>   # Moreover, Opera has lazy loading of images (only loading images
> >   # that are rendered or have some event handlers or were created with
> >   # new Image() etc), so we'd probably want to just load the image when
> >   # the script tries  to draw it instead of throwing.
> >
>
> By then it's too late to load the image in time to draw it, since drawImage
> needs to be able to be completed synchronously.  Also, even if you happen
> to be able to safely get the image synchronously (eg. if it's in memory
> cache or something), the draw is would still be required to not happen,
> since img.complete was false.
>
> --
> Glenn Maynard
>

Received on Friday, 1 March 2013 17:35:08 UTC