[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

Chris Dumez <cdumez at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |---

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

-- 
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/1e007591/attachment.htm>