[Webkit-unassigned] [Bug 252664] REGRESSION: Previewing projects broken in Construct 3 web app with Safari TP 163

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=252664

--- Comment #13 from Chris Dumez <cdumez at apple.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230227/3ac72eed/attachment-0001.htm>