Closed Bug 1497925 Opened Last year Closed Last year

createImageBitmap fails with particular content types

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: jaffathecake, Assigned: baku)

Details

Attachments

(1 file, 1 obsolete file)

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
Flags: needinfo?(amarchesini)
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)
Attached patch image.patch (obsolete) — Splinter Review
Assignee: nobody → amarchesini
Flags: needinfo?(aosmond)
Attachment #9018790 - Flags: review?(aosmond)
Attached patch image.patchSplinter Review
Attachment #9018790 - Attachment is obsolete: true
Attachment #9018790 - Flags: review?(aosmond)
Attachment #9018953 - Flags: review?(aosmond)
Attachment #9018953 - Flags: review?(aosmond) → review+
Pushed by amarchesini@mozilla.com:
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
https://hg.mozilla.org/mozilla-central/rev/cdc621a21acc
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Upstream PR merged
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.