Bug 279458 – WindowClient.matchAll resolves promise too early

• Component: Service Workers
• Status: RESOLVED FIXED

[Ben Nham]

Devs are reporting that WindowClient.matchAll sometimes resolves its promise too early, e.g. trying to postMessage to a matched client sometimes fails. See https://bugs.webkit.org/show_bug.cgi?id=268797 for more details.

At first glance, this sounds somewhat similar to these bugs where we were trying to focus a WindowClient early in its lifecycle:

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

In those bugs the client wasn't ready to accept the focus event so focus failed. Maybe something similar is happening with other methods you can perform on WindowClient.

[Radar WebKit Bug Importer]

<rdar://problem/135742835>

[youenn fablet]

Created attachment 473069 [details]
Patch delaying matchAll and get

[youenn fablet]

I uploaded the patch above.
Looking at the results though, it is not compatible with the WPT tests.

This exhibits 
Some service workers expect get/matchAll to resolve before actually answering the fetch event.
Some tests that fail:
- https://wpt.fyi/results/service-workers/service-worker/controlled-iframe-postMessage.https.html. It expects get to resolve. Chrome is timing out like Safari would with this patch. Firefox and stock Safari are passing the test.
- https://wpt.fyi/results/service-workers/service-worker/navigation-preload/redirect.https.html. It expects matchAll() to resolve. All browsers are passing but it is unclear whether the same set of clients are matching in all browsers.

I did some tests to check what matchAll and get give in the case of a being fetched new iframe:

1. matchAll
- Chrome does not list the iframe client
- Firefox lists the iframe client as 'about:blank'
- Safari lists the iframe client with its request URL

2. get
- Chrome does not list the iframe client
- Firefox lists the iframe client as 'about:blank'
- Safari lists the iframe client with its request URL

I'll update the patch to align with Chrome for matchAll.
This will reduce the possibility of web pages trying to focus/openWindow/postMessage clients that are not yet ready.
This is aligned with the spec ignoring clients whose execution ready flag (https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-execution-ready-flag) is not set.

[youenn fablet]

> (https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-
> execution-ready-flag) is not set.

This flag is set when document becomes active: https://html.spec.whatwg.org/multipage/browsing-the-web.html#make-active

[youenn fablet]

I filed https://bugs.webkit.org/show_bug.cgi?id=282233 to handle the case of get.

[EWS]

Committed 285953@main (1c96accc39ab): <https://commits.webkit.org/285953@main>

Reviewed commits have been landed. Closing PR #35858 and removing active labels.