Closed Bug 1497925 Opened Last year Closed Last year
Image Bitmap fails with particular content types
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce: Some servers, such as Webpack's dev server, serve images with content types like 'image/png; charset=UTF-8'. Firefox can display these images fine. However, createImageBitmap will blobs with types like this. Demo: https://static-misc.glitch.me/firefox-createimagebitmap-bug. Actual results: createImageBitmap rejects with "InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable" Expected results: The bitmap should have been created. View the demo in Chrome/Safari for the correct result.
"createImageBitmap will blobs with types like this" should be "createImageBitmap will *reject* blobs with types like this"
On the HTTP path, we properly parse the MIME type to extract the content type and the content charset, using: https://searchfox.org/mozilla-central/rev/eef79962ba73f7759fd74da658f6e5ceae0fc730/netwerk/base/nsURLHelper.h#201 It seems we are just passing it straight through on the createImageBitmap path. The blobs should probably be parsing the MIME type like the network? https://searchfox.org/mozilla-central/rev/eef79962ba73f7759fd74da658f6e5ceae0fc730/dom/file/Blob.cpp#245
Status: UNCONFIRMED → NEW
Component: Canvas: 2D → DOM
Ever confirmed: true
What you are proposing is against the current fetch spec. https://fetch.spec.whatwg.org/#concept-header-extract-mime-type says: "To extract a MIME type from a header list (headers), run these steps: Let mimeType be the result of extracting header list values given `Content-Type` and headers. If mimeType is null or failure, then return the empty byte sequence. Return mimeType, byte-lowercased." The bug here is not in the blob.type, but in how we implement the CreateImageBitmap spec: https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#dom-createimagebitmap: "Let imageData be the result of reading image's data. If an error occurs during reading of the object, then reject p with an \"InvalidStateError\" DOMException and abort these steps. Apply the image sniffing rules to determine the file format of imageData, with MIME type of image (as given by image's type attribute) giving the official type." It seems that we should not relay on the blob type at all. But currently we use the type. The failure happens here: https://searchfox.org/mozilla-central/rev/c56977420df7a1b692ce0f7e499ddb364d9fd7b2/image/imgTools.cpp#285
Flags: needinfo?(amarchesini) → needinfo?(aosmond)
Assignee: nobody → amarchesini
Attachment #9018790 - Flags: review?(aosmond)
Attachment #9018953 - Flags: review?(aosmond) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/cdc621a21acc CreateImageBitmap must ignore the Blob.type value, r=aosmond
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/13695 for changes under testing/web-platform/tests
Upstream PR merged
You need to log in before you can comment on or make changes to this bug.