Bug 253431

Summary: OffscreenCanvas missing WebGL support breaks all Construct 3 content
Product: WebKit Reporter: Ashley Gullen <ashley>
Component: WebGLAssignee: Matt Woodrow <mattwoodrow>
Status: RESOLVED FIXED    
Severity: Major CC: dino, karlcow, kbr, kkinnunen, mattwoodrow, mjs, tomac, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 16   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=254071
https://bugs.webkit.org/show_bug.cgi?id=263010
Attachments:
Description Flags
Minimal repro none

Ashley Gullen
Reported 2023-03-06 05:19:01 PST
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.
Attachments
Minimal repro (514 bytes, application/x-zip-compressed)
2023-03-06 05:19 PST, Ashley Gullen 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2023-03-06 18:41:14 PST
<rdar://problem/106341361>
Dean Jackson
Comment 2 2023-03-09 10:38:59 PST
> 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
Comment 3 2023-03-09 10:43:19 PST
> 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
Comment 4 2023-03-09 10:44:57 PST
Oh, and we have disabled main-thread WebGL for OffscreenCanvas.
Maciej Stachowiak
Comment 5 2023-03-09 10:46:10 PST
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
Comment 6 2023-03-09 10:53:50 PST
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
Comment 7 2023-03-09 11:08:41 PST
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
Comment 8 2023-03-09 11:47:11 PST
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
Comment 9 2023-03-10 03:03:15 PST
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
Comment 10 2023-03-10 03:18:30 PST
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
Comment 11 2023-03-10 03:25:56 PST
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
Comment 12 2023-03-10 04:27:25 PST
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
Comment 13 2023-03-10 11:23:56 PST
Thanks a lot for all the details. That should help.
Matt Woodrow
Comment 14 2023-03-12 15:35:30 PDT
Pull request: https://github.com/apple/WebKit/pull/445
EWS
Comment 15 2023-03-13 14:54:48 PDT
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
Comment 16 2023-03-14 05:36:39 PDT
May I ask what has actually been done to resolve this? None of the previous links appear to work for me.
Karl Dubost
Comment 17 2023-03-19 19:32:19 PDT
Ashley, The quirk will desactivate OffscreenCanvas when `window.C3_IsSupported` for versions of Safari where it is necessary per your recommendation.
EWS
Comment 18 2023-04-07 17:54:20 PDT
Committed 262741@main (171dfb71ff1d): <https://commits.webkit.org/262741@main> Reviewed commits have been landed. Closing PR #12457 and removing active labels.
Ashley Gullen
Comment 19 2023-10-11 06:19:11 PDT
Please note I have filed issue 263010 requesting removal of the quirk added here, as it is no longer necessary with Safari 17+.
Note You need to log in before you can comment on or make changes to this bug.