Bug 253431 – OffscreenCanvas missing WebGL support breaks all Construct 3 content

• Component: WebGL
• Status: RESOLVED FIXED

[Ashley Gullen]

Created attachment 465313 [details]
Minimal repro

Safari 16.4 appears to ship only a partial implementation of OffscreenCanvas, with only support for the 2D context. The beta release notes include the line: "Added support for 2D-only OffscreenCanvas."

Calling `offscreenCanvas.getContext("webgl2")` in a worker returns null in Safari TP 164. This breaks all web content that feature-detects OffscreenCanvas with `typeof OffscreenCanvas !== "undefined"`, including all iOS apps and web content made by Construct (www.construct.net) published over the past few years. We can publish an update that works around this, but it will still cause major disruption as all of the past few years of content will all need updating, and some of it will not be actively maintained.

Sample web content broken in Safari TP 164: https://downloads.scirra.com/labs/spaceblaster/

Minimal repro attached. This attempts to get an OffscreenCanvas WebGL 2 context in both the DOM and a Web Worker. It works in the DOM but returns null in the worker in latest Safari only. (This also makes feature detection harder - you can't detect missing OffscreenCanvas support for WebGL in the DOM, prior to starting a worker.) Both Chrome and Firefox support WebGL in an OffscreenCanvas in a worker, so only Safari has this issue.

Please do not ship features if they are only partially supported! It means it passes feature detection but breaks. Using WebGL in an OffscreenCanvas in a worker is a major use case for both us and the OffscreenCanvas API. I would ask that OffscreenCanvas is unshipped from Safari releases until it is completed.

[Radar WebKit Bug Importer]

<rdar://problem/106341361>

[Dean Jackson]

> Please do not ship features if they are only partially supported! It means it passes feature detection but breaks. Using WebGL in an OffscreenCanvas in a worker is a major use case for both us and the OffscreenCanvas API. I would ask that OffscreenCanvas is unshipped from Safari releases until it is completed.

The OffscreenCanvas API does not require WebGL support at all, so it's totally valid to ship in this state. I'm sorry it has uncovered a bug in your feature detection code.

WebGL support in OffscreenCanvas is coming in a future release. Meanwhile there is lots of content that benefits from the 2D functionality, so I think it would be better for you to fix your bug than for us to hold back.

We *could* consider removing the OffscreenCanvas + WebGL support in non-worker situations.

[Dean Jackson]

> We *could* consider removing the OffscreenCanvas + WebGL support in non-worker situations.

… but that wouldn't actually help you it seems. You assume WebGL if you see OffscreenCanvas, which is a mistake. e.g. you don't assume that WebGPU, or ImageBitmap, or any future rendering context, is supported in OffscreenCanvas, even though that will eventually happen.

[Dean Jackson]

Oh, and we have disabled main-thread WebGL for OffscreenCanvas.

[Maciej Stachowiak]

A challenge here is that the arguably faulty feature detection is in a framework, not just a specific website. If it was a specific website we could easily make a quirk to avoid the web compat problem in the short term. Is there a way to detect that a site or app is using Construct?

[Dean Jackson]

One thing we could consider is adding a quirk that disables OffscreenCanvas just for pages that use Construct. Two issues:

1. How can we detect this? Do you have any advice? Easiest would be noticing scripts that load from a domain, but that won't address content that loads from its own domain.

2. You'd effectively never get OffscreenCanvas in Safari, unless you could work around our detection in newer versions.

[Maciej Stachowiak]

If we add a quirk, we would presumably remove it when/if we support WebGL OffscreenCanvas, so I'm not sure the "don't get it forever" thing is true.

[Karl Dubost]

Ashley, I see in https://downloads.scirra.com/labs/spaceblaster/
that the library is creating a series of window.C3* objects, do you happen to publish the version number of the library currently being used by the site?

So in the case of a Quirk, that we could sniff early enough the library and deactivate what is required in case people have local copies of the library.

[Ashley Gullen]

The presence of a script named c3runtime.js should be sufficient to detect Construct 3 content.

But this also breaks iOS apps published in the App Store running in WKWebView using Cordova. Will the quirk cover those too?

Why not postpone OffscreenCanvas until the next release and ship with WebGL support included? It would be great to see OffscreenCanvas support in Safari, but surely it's not urgent to ship it right now?

[Ashley Gullen]

Actually, relying on c3runtime.js is tricky because it can sometimes load in the DOM or the worker depending on feature detection. The presence of a global variable on the main thread named window.c3_runtimeInterface would probably be a better way to detect our engine.

Further I'd point out that most developers refer to sources like MDN rather than the spec for documentation, and it wasn't previously clear from there that it was possible or allowed for mixed support for contexts between HTMLCanvasElement and OffscreenCanvas. Chrome 69 first added support for OffscreenCanvas in 2018, supporting both the 2D and WebGL contexts at launch, and Firefox 105 also added support for OffscreenCanvas last year supporting both the 2D and WebGL contexts at launch. So I would suggest that given there is over 4 years of web compatibility precedent for OffscreenCanvas to support all contexts or not be supported at all, perhaps one can understand why web developers would make that assumption, even if technically incorrect according to the spec, and perhaps there is other web content out there that will be affected for the same reason.

[Ashley Gullen]

I took a closer look at our feature detection code, and it looks like we actually already unconditionally disable OffscreenCanvas in Cordova on iOS. So there should not be a risk to iOS apps published with Cordova or WKWebView, at least for our content. Apologies for the confusion.

If you want to proceed with a Safari quirk that detects our engine, I think that window.c3_runtimeInterface is actually created after we run feature detection. Our engine will set window.C3_IsSupported to true prior to running feature detection for OffscreenCanvas, so that may be a better signal.

[Ashley Gullen]

I just want to make one more point: the spec should reflect web reality - it shouldn't be a reason to impose breaking changes on the web. For example when the new Array method flatten() was found to break existing web content, it was renamed to flat() to avoid breakage. Web compatibility should have priority and if something in the spec risks causing breakage on the web, then the spec should be changed. So on this basis I would suggest the spec should be changed to require that OffscreenCanvas supports all the same contexts that HTMLCanvasElement does.

[Karl Dubost]

Thanks a lot for all the details. That should help.

[Matt Woodrow]

Pull request: https://github.com/apple/WebKit/pull/445

[EWS]

Committed 259548.408@safari-7615-branch (0489426718c9): <https://commits.webkit.org/259548.408@safari-7615-branch>

Reviewed commits have been landed. Closing PR #445 and removing active labels.

[Ashley Gullen]

May I ask what has actually been done to resolve this? None of the previous links appear to work for me.

[Karl Dubost]

Ashley,

The quirk will desactivate OffscreenCanvas when `window.C3_IsSupported` for versions of Safari where it is necessary per your recommendation.

[EWS]

Committed 262741@main (171dfb71ff1d): <https://commits.webkit.org/262741@main>

Reviewed commits have been landed. Closing PR #12457 and removing active labels.

[Ashley Gullen]

Please note I have filed issue 263010 requesting removal of the quirk added here, as it is no longer necessary with Safari 17+.