Bug 252664 – REGRESSION: Previewing projects broken in Construct 3 web app with Safari TP 163

• Status: RESOLVED
• Resolution: INVALID
• Component: Service Workers

[Ashley Gullen]

This is a major regression with our web app in Safari TP 163. It prevents users from being able to preview their work.

Steps to reproduce:

1. Open this link in Safari TP 163: https://editor.construct.net/#open=ghost-shooter-tut (dismiss any dialogs or prompts along the way)
2. Press F5, or click the "Play" button on the toolbar, to preview the project (you may need to approve popups)

Expected result: the game should preview in a popup window.

Observed result: the preview window gets stuck saying "Loading". In the console there are 404 errors for missing files. However these are all files served by a Service Worker, and aren't actually on the server. Therefore this indicates an incompatibility with Service Workers in Safari TP 163.

What I suspect is happening here is our engine is now feature-detecting OffscreenCanvas now that Safari TP supports all the necessary features. In our engine this is gated on supporting OffscreenCanvas, module type workers, and the User Activation API. These are all newly supported in Safari TP and so our engine is now creating a module worker to load the engine in ready for rendering off main thread with OffscreenCanvas. However the preview relies on the Service Worker being able to serve some local assets for specific URLs, which are the ones that are returning 404 not found in the console. Therefore I suspect the issue is that module type workers change something about how requests get routed through the SW and this breaks our web app. However I would point out that this has been supported for a long time by Chrome and has been working correctly there.

[Radar WebKit Bug Importer]

<rdar://problem/105728117>

[Alexey Proskuryakov]

*** This bug has been marked as a duplicate of bug 252474 ***

[Ashley Gullen]

This issue is not a duplicate of issue 252474! Please unmerge them or you will likely leave a breaking change in Safari!

[Chris Dumez]

https://preview.construct.net/internals/expFuncs.js is one of the failing URLs. Looking at our logging, I see that we decide not to use the service worker for this load because `loader.parameters().serviceWorkersMode == ServiceWorkersMode::None`

[Chris Dumez]

(In reply to Chris Dumez from comment #4)
> https://preview.construct.net/internals/expFuncs.js is one of the failing
> URLs. Looking at our logging, I see that we decide not to use the service
> worker for this load because `loader.parameters().serviceWorkersMode ==
> ServiceWorkersMode::None`

I see 2 attempts to load https://preview.construct.net/internals/expFuncs.js.

The first one comes from a dedicated worker and gets handled by the service worker, as expected.

The second one comes from a service worker and that's the one which doesn't get handled by a service worker (which makes sense I think).

It is unclear to me at this point why the service worker tries to load the script since it is not a valid URL (404).

[Chris Dumez]

A dedicated worker does a load for https://preview.construct.net/internals/expFuncs.js. This gets intercepted by a service worker (sw.js). We fire a FetchEvent for this load to the service worker and the service worker calls FetchEvent.respondWith() with a promise. However, this promise never gets settled.

Then I see the service worker trying to load https://preview.construct.net/internals/expFuncs.js and failing with a 404.

I am not sure what's supposed to happen here but given that the URL is 404, I assume the service worker is supposed to return something cached instead of trying to load that URL itself.

[Chris Dumez]

When getting the FetchEvent, the service worker runs this code:
```
const storage = GetServeBlobsStorage();
let clientValue = await storage.getItem(clientId);
```

storage has no key matching this clientId (dedicated worker clientId). It has 1 key but it is another clientId.

[Chris Dumez]

Would you be able to work around this for now?

Given that this regressed when enabling a major feature, it may take us a little while to investigate and ship a fix.

If you do end up working around the issue on your side though, I'd appreciate if you could share a URL that can still reproduce the bug so we can continue our investigation.

[Ashley Gullen]

I spent a while debugging this and I think what happens is this. It's part of a feature to serve local data from URLs using the SW.

1. On startup the main window posts to the SW a map of blobs to serve locally (URL string keys -> blob values)
2. The SW receives this map, and stores it by the client ID it came from.
3. Later fetch events in the SW look up the client ID of the fetch event. If it finds a map of blobs to serve for the client ID, then it looks for that URL in the map. If the lookup succeeds it responds to the fetch with that blob, else the request goes out to network.

What I believe is happening is that when running in a Web Worker, the client IDs for fetch events from the worker are different to those from the main window. Therefore the SW does not find the map of blobs to serve, and falls back to going to network (which returns 404).

In Chrome the client IDs for fetch events from the Web Worker is the same as those for the main window, and therefore the lookup succeeds and content is served from the map.

So this seems to be a compat difference between Chrome and Safari over whether fetch events from the main window and a web worker are the same or not. It seems in both cases, clients.matchAll() in the SW returns only the main window and not any web workers; this seems to suggest to me that Safari TP is incorrect here? I'm not sure what the spec says though.

NOTE: this issue is still marked resolved duplicate of an unrelated issue. Please reopen it as there is evidence of a compat issue/breaking change in Safari that is yet to be resolved.

[Ashley Gullen]

I'm also not sure how to work around this. How can the Service Worker identify the main window client ID from a fetch event for a worker with a different client ID? The Client API does not appear to provide any association, and SW clients don't know their own ID. I guess our only workaround would be to entirely disable the use of workers, which is a shame.

[Chris Dumez]

(In reply to Ashley Gullen from comment #9)
> I spent a while debugging this and I think what happens is this. It's part
> of a feature to serve local data from URLs using the SW.
> 
> 1. On startup the main window posts to the SW a map of blobs to serve
> locally (URL string keys -> blob values)
> 2. The SW receives this map, and stores it by the client ID it came from.
> 3. Later fetch events in the SW look up the client ID of the fetch event. If
> it finds a map of blobs to serve for the client ID, then it looks for that
> URL in the map. If the lookup succeeds it responds to the fetch with that
> blob, else the request goes out to network.
> 
> What I believe is happening is that when running in a Web Worker, the client
> IDs for fetch events from the worker are different to those from the main
> window. Therefore the SW does not find the map of blobs to serve, and falls
> back to going to network (which returns 404).
> 
> In Chrome the client IDs for fetch events from the Web Worker is the same as
> those for the main window, and therefore the lookup succeeds and content is
> served from the map.
> 
> So this seems to be a compat difference between Chrome and Safari over
> whether fetch events from the main window and a web worker are the same or
> not. It seems in both cases, clients.matchAll() in the SW returns only the
> main window and not any web workers; this seems to suggest to me that Safari
> TP is incorrect here? I'm not sure what the spec says though.
> 
> NOTE: this issue is still marked resolved duplicate of an unrelated issue.
> Please reopen it as there is evidence of a compat issue/breaking change in
> Safari that is yet to be resolved.

From the specification, we can see that the client type can be "worker":
https://www.w3.org/TR/service-workers/#enumdef-clienttype

A service worker client is an environment:
https://www.w3.org/TR/service-workers/#dfn-service-worker-client

And an environment has a unique ID that is an opaque string:
https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-id

I fully expect that if a dedicated worker does a fetch then the FetchEvent will have a clientId that is the dedicated worker's ID, not the main window's ID. If that's not the case in Chrome, then I suspect they have a bug.

The fact that `clients.matchAll()` doesn't return the web workers is unexpected though.

[Chris Dumez]

(In reply to Ashley Gullen from comment #10)
> I'm also not sure how to work around this. How can the Service Worker
> identify the main window client ID from a fetch event for a worker with a
> different client ID? The Client API does not appear to provide any
> association, and SW clients don't know their own ID. I guess our only
> workaround would be to entirely disable the use of workers, which is a shame.

We will likely commit a quirk that disables OffscreenCanvas for your site specifically to unbreak this while we investigate the real issue. I thought you might prefer to be in control of the workaround/quirk.

[Chris Dumez]

(In reply to Chris Dumez from comment #11)
> (In reply to Ashley Gullen from comment #9)
> > I spent a while debugging this and I think what happens is this. It's part
> > of a feature to serve local data from URLs using the SW.
> > 
> > 1. On startup the main window posts to the SW a map of blobs to serve
> > locally (URL string keys -> blob values)
> > 2. The SW receives this map, and stores it by the client ID it came from.
> > 3. Later fetch events in the SW look up the client ID of the fetch event. If
> > it finds a map of blobs to serve for the client ID, then it looks for that
> > URL in the map. If the lookup succeeds it responds to the fetch with that
> > blob, else the request goes out to network.
> > 
> > What I believe is happening is that when running in a Web Worker, the client
> > IDs for fetch events from the worker are different to those from the main
> > window. Therefore the SW does not find the map of blobs to serve, and falls
> > back to going to network (which returns 404).
> > 
> > In Chrome the client IDs for fetch events from the Web Worker is the same as
> > those for the main window, and therefore the lookup succeeds and content is
> > served from the map.
> > 
> > So this seems to be a compat difference between Chrome and Safari over
> > whether fetch events from the main window and a web worker are the same or
> > not. It seems in both cases, clients.matchAll() in the SW returns only the
> > main window and not any web workers; this seems to suggest to me that Safari
> > TP is incorrect here? I'm not sure what the spec says though.
> > 
> > NOTE: this issue is still marked resolved duplicate of an unrelated issue.
> > Please reopen it as there is evidence of a compat issue/breaking change in
> > Safari that is yet to be resolved.
> 
> From the specification, we can see that the client type can be "worker":
> https://www.w3.org/TR/service-workers/#enumdef-clienttype
> 
> A service worker client is an environment:
> https://www.w3.org/TR/service-workers/#dfn-service-worker-client
> 
> And an environment has a unique ID that is an opaque string:
> https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-id
> 
> I fully expect that if a dedicated worker does a fetch then the FetchEvent
> will have a clientId that is the dedicated worker's ID, not the main
> window's ID. If that's not the case in Chrome, then I suspect they have a
> bug.
> 
> The fact that `clients.matchAll()` doesn't return the web workers is
> unexpected though.

Note that by default, clients.matchAll() only returns window clients. However, you can request ALL clients via:
clients.matchAll({ type: "all" })

Is this what you tried? It is also possible to add `includeUncontrolled: true` to this dictionary in case we have an issue where the worker client is not marked as controlled.

[Chris Dumez]

(In reply to Chris Dumez from comment #13)
> (In reply to Chris Dumez from comment #11)
> > (In reply to Ashley Gullen from comment #9)
> > > I spent a while debugging this and I think what happens is this. It's part
> > > of a feature to serve local data from URLs using the SW.
> > > 
> > > 1. On startup the main window posts to the SW a map of blobs to serve
> > > locally (URL string keys -> blob values)
> > > 2. The SW receives this map, and stores it by the client ID it came from.
> > > 3. Later fetch events in the SW look up the client ID of the fetch event. If
> > > it finds a map of blobs to serve for the client ID, then it looks for that
> > > URL in the map. If the lookup succeeds it responds to the fetch with that
> > > blob, else the request goes out to network.
> > > 
> > > What I believe is happening is that when running in a Web Worker, the client
> > > IDs for fetch events from the worker are different to those from the main
> > > window. Therefore the SW does not find the map of blobs to serve, and falls
> > > back to going to network (which returns 404).
> > > 
> > > In Chrome the client IDs for fetch events from the Web Worker is the same as
> > > those for the main window, and therefore the lookup succeeds and content is
> > > served from the map.
> > > 
> > > So this seems to be a compat difference between Chrome and Safari over
> > > whether fetch events from the main window and a web worker are the same or
> > > not. It seems in both cases, clients.matchAll() in the SW returns only the
> > > main window and not any web workers; this seems to suggest to me that Safari
> > > TP is incorrect here? I'm not sure what the spec says though.
> > > 
> > > NOTE: this issue is still marked resolved duplicate of an unrelated issue.
> > > Please reopen it as there is evidence of a compat issue/breaking change in
> > > Safari that is yet to be resolved.
> > 
> > From the specification, we can see that the client type can be "worker":
> > https://www.w3.org/TR/service-workers/#enumdef-clienttype
> > 
> > A service worker client is an environment:
> > https://www.w3.org/TR/service-workers/#dfn-service-worker-client
> > 
> > And an environment has a unique ID that is an opaque string:
> > https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-id
> > 
> > I fully expect that if a dedicated worker does a fetch then the FetchEvent
> > will have a clientId that is the dedicated worker's ID, not the main
> > window's ID. If that's not the case in Chrome, then I suspect they have a
> > bug.
> > 
> > The fact that `clients.matchAll()` doesn't return the web workers is
> > unexpected though.
> 
> Note that by default, clients.matchAll() only returns window clients.
> However, you can request ALL clients via:
> clients.matchAll({ type: "all" })
> 
> Is this what you tried? It is also possible to add `includeUncontrolled:
> true` to this dictionary in case we have an issue where the worker client is
> not marked as controlled.

Just tried on your site:
```
> clients.matchAll({ type: "all" }).then((clients) => { console.log(clients); })
< Promise {status: "pending"}
[Log] Array (4)
0 WindowClient {visibilityState: "hidden", focused: false, ancestorOrigins: [], focus: function, navigate: function, …}
1 Client {url: "blob:https://preview.construct.net/de19de6e-e748-44fa-b892-49e7ab402229", frameType: "none", type: "worker", id: "dc86c648-60d7-4a3b-b262-be9352b3e5cd", postMessage: function}
2 Client {url: "https://preview.construct.net/previewworker.js", frameType: "none", type: "worker", id: "7caea875-b754-4420-849a-575cb968b0c4", postMessage: function}
3 Client {url: "blob:https://preview.construct.net/191f3d6b-7528-4cc4-80af-6d98c5e5ebce", frameType: "none", type: "worker", id: "61edf26d-b0b8-4e42-9228-e4d3d7be4046", postMessage: function}

```

Seems to work as expected if you use the matchAll() API correctly and also request worker clients.

I don't think we have evidence of a WebKit bug yet. It seems there is a difference in behavior with Blink but I'd argue that our behavior is correct here.

[Chris Dumez]

(In reply to Chris Dumez from comment #14)
> (In reply to Chris Dumez from comment #13)
> > (In reply to Chris Dumez from comment #11)
> > > (In reply to Ashley Gullen from comment #9)
> > > > I spent a while debugging this and I think what happens is this. It's part
> > > > of a feature to serve local data from URLs using the SW.
> > > > 
> > > > 1. On startup the main window posts to the SW a map of blobs to serve
> > > > locally (URL string keys -> blob values)
> > > > 2. The SW receives this map, and stores it by the client ID it came from.
> > > > 3. Later fetch events in the SW look up the client ID of the fetch event. If
> > > > it finds a map of blobs to serve for the client ID, then it looks for that
> > > > URL in the map. If the lookup succeeds it responds to the fetch with that
> > > > blob, else the request goes out to network.
> > > > 
> > > > What I believe is happening is that when running in a Web Worker, the client
> > > > IDs for fetch events from the worker are different to those from the main
> > > > window. Therefore the SW does not find the map of blobs to serve, and falls
> > > > back to going to network (which returns 404).
> > > > 
> > > > In Chrome the client IDs for fetch events from the Web Worker is the same as
> > > > those for the main window, and therefore the lookup succeeds and content is
> > > > served from the map.
> > > > 
> > > > So this seems to be a compat difference between Chrome and Safari over
> > > > whether fetch events from the main window and a web worker are the same or
> > > > not. It seems in both cases, clients.matchAll() in the SW returns only the
> > > > main window and not any web workers; this seems to suggest to me that Safari
> > > > TP is incorrect here? I'm not sure what the spec says though.
> > > > 
> > > > NOTE: this issue is still marked resolved duplicate of an unrelated issue.
> > > > Please reopen it as there is evidence of a compat issue/breaking change in
> > > > Safari that is yet to be resolved.
> > > 
> > > From the specification, we can see that the client type can be "worker":
> > > https://www.w3.org/TR/service-workers/#enumdef-clienttype
> > > 
> > > A service worker client is an environment:
> > > https://www.w3.org/TR/service-workers/#dfn-service-worker-client
> > > 
> > > And an environment has a unique ID that is an opaque string:
> > > https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-id
> > > 
> > > I fully expect that if a dedicated worker does a fetch then the FetchEvent
> > > will have a clientId that is the dedicated worker's ID, not the main
> > > window's ID. If that's not the case in Chrome, then I suspect they have a
> > > bug.
> > > 
> > > The fact that `clients.matchAll()` doesn't return the web workers is
> > > unexpected though.
> > 
> > Note that by default, clients.matchAll() only returns window clients.
> > However, you can request ALL clients via:
> > clients.matchAll({ type: "all" })
> > 
> > Is this what you tried? It is also possible to add `includeUncontrolled:
> > true` to this dictionary in case we have an issue where the worker client is
> > not marked as controlled.
> 
> Just tried on your site:
> ```
> > clients.matchAll({ type: "all" }).then((clients) => { console.log(clients); })
> < Promise {status: "pending"}
> [Log] Array (4)
> 0 WindowClient {visibilityState: "hidden", focused: false, ancestorOrigins:
> [], focus: function, navigate: function, …}
> 1 Client {url:
> "blob:https://preview.construct.net/de19de6e-e748-44fa-b892-49e7ab402229",
> frameType: "none", type: "worker", id:
> "dc86c648-60d7-4a3b-b262-be9352b3e5cd", postMessage: function}
> 2 Client {url: "https://preview.construct.net/previewworker.js", frameType:
> "none", type: "worker", id: "7caea875-b754-4420-849a-575cb968b0c4",
> postMessage: function}
> 3 Client {url:
> "blob:https://preview.construct.net/191f3d6b-7528-4cc4-80af-6d98c5e5ebce",
> frameType: "none", type: "worker", id:
> "61edf26d-b0b8-4e42-9228-e4d3d7be4046", postMessage: function}
> 
> ```
> 
> Seems to work as expected if you use the matchAll() API correctly and also
> request worker clients.
> 
> I don't think we have evidence of a WebKit bug yet. It seems there is a
> difference in behavior with Blink but I'd argue that our behavior is correct
> here.

Youenn investigated and found this standards test:
https://wpt.fyi/results/service-workers/service-worker/worker-client-id.https.html?label=experimental&label=master&aligned&view=subtest

It does confirm your findings that Chrome uses the same client ID for the worker and the main Window. However, it also confirms that Chrome's behavior is non-standard and that both Safari and Firefox follow the specification.

Marking bug as Invalid since it seems the site relies on Chrome-specific, non-standard behavior.

[youenn fablet]

@Ashley, you should be able to update the service worker to match both Chrome and Safari behavior while Chrome is catching up.
The fetch event corresponding to the worker script load should have:
- A destination equal to "worker"
- A clientId being the one of the window creating the worker
- A resultingClientId being the worker Id.

The worker Id will be the one associated to fetches done by the worker.
This should allow youth build a dedicated worker id -> window id table.

AFAIK, this should work in both Firefox and recent Safari.
Hope this helps.

[Ashley Gullen]

Thanks for the investigation all. Ouch, looks like we ended up relying on a Chrome bug.

For now, I have added code that does user-agent sniffing and blanket disables our use of OffscreenCanvas on Safari. I would prefer to ship that solution since as you say it leaves us in control of it. However this may end up taking several weeks to roll out to all our users as per our usual release cycle and that would need to happen before the next version of Safari ships. When is that scheduled to happen? If it is very soon then perhaps adding a quirk would be a better way to avoid breakage in the short term.

I will also look in to updating the SW to map client IDs for workers, but similarly we will have to be careful how we roll that out.

[Chris Dumez]

(In reply to Ashley Gullen from comment #17)
> Thanks for the investigation all. Ouch, looks like we ended up relying on a
> Chrome bug.
> 
> For now, I have added code that does user-agent sniffing and blanket
> disables our use of OffscreenCanvas on Safari. I would prefer to ship that
> solution since as you say it leaves us in control of it. However this may
> end up taking several weeks to roll out to all our users as per our usual
> release cycle and that would need to happen before the next version of
> Safari ships. When is that scheduled to happen? If it is very soon then
> perhaps adding a quirk would be a better way to avoid breakage in the short
> term.
> 
> I will also look in to updating the SW to map client IDs for workers, but
> similarly we will have to be careful how we roll that out.

We are unable to communicate Apple release dates.

[Ashley Gullen]

I appreciate all the engineering help but it is dispiriting to find the fate of the product my business depends on comes down to "We are unable to communicate Apple release dates". I guess now I have to go through the disruption of dropping everything and doing an emergency response, merely because Apple can't tell me when this update will ship. I don't think it's acceptable for Apple to put us in this situation and I suppose all I can do is continuing to advocate for change at Apple to whoever will listen.

[Brent Fulgham]

(In reply to Ashley Gullen from comment #19)
> I appreciate all the engineering help but it is dispiriting to find the fate
> of the product my business depends on comes down to "We are unable to
> communicate Apple release dates". I guess now I have to go through the
> disruption of dropping everything and doing an emergency response, merely
> because Apple can't tell me when this update will ship. I don't think it's
> acceptable for Apple to put us in this situation and I suppose all I can do
> is continuing to advocate for change at Apple to whoever will listen.

I understand your frustration, but surely you can't view Apple implementing SW and Offscreen Canvas behavior per the W3C standard as doing something wrong?

If your concern is around our Safari releases with Offscreen Canvas support, we can share that we have begun public seeding of this release, which would indicate we plan to ship this soon.

As Chris has pointed out, the WebKit Open Source Project has no control over Apple software release dates, nor permission to share details around shipment dates even if we knew them.

[Ashley Gullen]

My frustration is with Apple and their management of Safari releases, not the WebKit project - my comment was in response to "Apple release dates". I accept that there is not a problem with Safari in this case. However bugs happen, and merely knowing a release date is very helpful in order to plan our response to it. All Apple need to do to avoid causing us disruption is tell us the earliest likely release date. Sure, release dates can slip, but it still provides something for us to plan around.

Apple's needless secrecy around release dates - and in other cases, even just knowing which version of Safari bug fixes are planned to ship in - has repeatedly caused us disruption and wasted time over the years, solely because Apple refuse to tell us basic information that they surely have internally. I can point to many past cases, not least of which was completely breaking WebAssembly for months and not providing any useful information about it whatsoever at any time. The secrecy is harmful to web developers and I doubt it achieves anything for Apple. Other browser vendors all have transparent processes and never cause us these kinds of problems.

This is such a frustrating and on-going problem for us, that if Apple refuse to publish basic information to help avoid causing us serious disruption, I feel like my only option is to talk to regulators and try to get them to force Apple to change. What else can I do to prevent this? For example if we get the real Chromium on iOS, at least we can give customers a workaround - but I'd much prefer it if we could make sure things keep working in Safari!

[Ashley Gullen]

I'd add that I don't know what "public seeding" means, how long it takes, or how long "soon" means, so I still don't know if release will be in 2 days, 2 weeks or 2 months.

[youenn fablet]

(In reply to Ashley Gullen from comment #22)
> I'd add that I don't know what "public seeding" means, how long it takes, or
> how long "soon" means, so I still don't know if release will be in 2 days, 2
> weeks or 2 months.

Looking at previous year release cycles may be helpful.

[Ashley Gullen]

If there's a lot at stake, I need to know that Apple hasn't changed their policy since last year. And if it's that consistent, why not just publish a release schedule so developers can plan around it and avoid disruption?

[Karl Dubost]

Ashley thanks a lot for the detailed reporting and interactions. That's useful. 
Reading Comment in https://bugs.webkit.org/show_bug.cgi?id=252664#c16

So the site relies on a Chrome bug.
https://bugs.chromium.org/p/chromium/issues/detail?id=832071
Probably there is a need of a comment on this bug to say that the current behavior  creates an issue for Safari (by setting the wrong expectations for webdevs.)


One question though. 
Ashley, does your application currently break in Firefox? (as Firefox and Safari share the same behavior).

I would recommend not doing User-Agent sniffing. Would it be possible to detect the different behavior with what Youenn provided? The returned objects being different that would make a better switch mode than UA sniffing. That would also make the system independent of any release dates.

[Ashley Gullen]

The breakage is in features gated on availability of the User Activation API and module type workers. These aren't supported in Firefox yet, but as things stood it would probably have been broken in Firefox too. However Firefox provide transparency around feature schedules and release dates, so we could at least plan around that.

I've updated our SW on an emergency schedule to work around this, but we've now run in to a difficult SW caching issue - it seems Safari keeps bringing back the old SW which has the issue... I really can't figure out why that is happening. Perhaps we need to wait out the HTTP cache? But I don't know if we can wait that long. So we added UA sniffing and turned off the affected feature. I never like doing that, but I can't plan for a better option.

[Ashley Gullen]

I was tied up with this issue lately but also just discovered another issue with OffscreenCanvas that breaks all existing published content made by Construct: https://bugs.webkit.org/show_bug.cgi?id=253431

Please don't ship OffscreenCanvas until it supports both the 2D and WebGL contexts. That will fix an even more serious compatibility problem, and also provide more time for us to deal with the consequences of the problem described here.