[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|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

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

-- 
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/2ff95b5b/attachment.htm>