Closed Bug 1472194 Opened 7 years ago Closed 6 years ago

Mysterious createImageBitmap(blob) error in our PWA in Firefox only

Categories

(Core :: Graphics: Canvas2D, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ashley, Unassigned)

References

()

Details

(Keywords: parity-chrome, parity-edge)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce: Load our PWA Construct 3 at https://editor.construct.net/r107-2/ (Note this loads a specific version of our PWA; use that URL to reproduce the issue since we worked around this bug in later versions.) Once it's loaded, cancel any dialogs that appear, then drag-and-drop this file in to the page: https://github.com/Scirra/Construct-3-bugs/files/1944814/cyborg.attack.zip This will open the file in our PWA. However it fails to load an image from the file. Actual results: The console reports: DOMException: "An attempt was made to use an object that is not, or is no longer, usable" A sprite that ought to appear in the main view appears as a red rectangle instead. (This is an error fallback in our code.) In both Chrome and Edge, it loads correctly and displays a graphic. When loading the file, our PWA will read a PNG file as a blob, and then as part of uploading it to a WebGL texture, calls createImageBitmap first if supported. It appears that the bug does not happen if we disable createImageBitmap in Firefox. So it appears that sometimes in Firefox using createImageBitmap(blob) incorrectly fails with an error. Expected results: createImageBitmap(blob) should always work, as it does in Chrome, and as it does in Firefox if you read the blob as a HTMLImageElement instead (which is our fallback path when createImageBitmap is not used).
Has STR: --- → yes
Component: Untriaged → DOM
Product: Firefox → Core
Version: 63 Branch → unspecified
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Component: DOM: Core & HTML → Canvas: 2D
Priority: P3 → --

The problem did not happen with latest Firefox release and nightly.

With mozregression, DOMException seemed to be addressed with the following range. All fixes belonged to "DOM: Core & HTML". Bug 1497925 might addressed the DOMException.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=969fc88ef9a4aa881650668a1ddc16318802ce5c&tochange=1dee16fa95e5257ecef4c8edf5e325732a4aa7dc

ashley, can you check if the problem is addressed with latest Firefox release? Thanks.

Flags: needinfo?(ashley)

I can no longer reproduce in Firefox 68 (stable) or Nightly 70. I also removed the workaround we were using in the latest version of our web app and retried, and it works correctly there as well with Firefox 68 and 70. So this appears to be fixed now.

Flags: needinfo?(ashley)

Thanks!

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.