Issue metadata
Sign in to add a comment
|
Canvas .drawImage not drawing images that haven't already been rendered
Reported by
s...@stuartpb.com,
Aug 14 2017
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
Steps to reproduce the problem:
1. Create an `img` element that is not part of the document tree (ie. just calling `document.createElement('img')` and not `.appendChild`).
2. Set that image's source to any URL that hasn't already been rendered in this session. Either a remote URL or a Data URL will work here.
3. Draw this image element to a canvas with `.getContext('2d').drawImage`.
See attached testcase (also available as https://testcases.github.io/drawimage-unrendered/index.html ).
What is the expected behavior?
The image should be drawn to the canvas (in the test case, a big blue square should appear).
What went wrong?
Nothing is drawn to the canvas (in the test case, the page is entirely white).
Did this work before? Yes I know this was working around a year ago when https://bugs.chromium.org/p/chromium/issues/detail?id=475009 was closed (note that none of the images in that issue's test case currently render at all).
Does this work in other browsers? Yes
Chrome version: 60.0.3112.90 Channel: n/a
OS Version: 10.0
Flash Version:
Tested both on my daily driver and current Canary (Version 62.0.3185.0 (Official Build) canary (64-bit)).
,
Aug 15 2017
,
Aug 15 2017
As of https://chromium.googlesource.com/chromium/src/+/b6403174c6111ea0947dc7cf8b1eb8a6f9e8546c, the URI image load is async in chromium, which is the spec compliant behavior. Tagging the bug as Won'tFix.
,
Aug 15 2017
So, for end developers, the solution to this would be to move the .drawImage call to a "load" event listener on the image after changing the 'src' attribute? On Tue, Aug 15, 2017, at 08:51 AM, zakerina… via monorail wrote:
,
Aug 15 2017
Or, more specifically (if I'm reading the [spec][] right), a "loadend" event? From what I remember, Chrome used to fire these load events inconsistently (meaning that developers had to both add an event listener *and* check the `complete` property, potentially releasing [Zalgo][] depending on whether the image was cached or not), so if this change made it so "loadend" can be depended upon as a universally reliable point of image readiness, it's a welcome one from me. [spec]: https://www.w3.org/TR/html5/embedded-content-0.html#the-img-element [Zalgo]: http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony
,
Aug 15 2017
I guess my complaint then would be: why does calling drawImage on an incomplete image cause *complete transparency to be drawn*, instead of raising an error, as it would if, say, the image source was a broken SVG image? The latter appears to be the behavior in Firefox: https://stackoverflow.com/questions/15679299/canvas-drawimage-fails |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by phistuck@chromium.org
, Aug 15 2017Labels: -Pri-2 Needs-Bisect Pri-1
Status: Untriaged (was: Unconfirmed)