WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 279458
WindowClient.matchAll resolves promise too early
https://bugs.webkit.org/show_bug.cgi?id=279458
Summary
WindowClient.matchAll resolves promise too early
Ben Nham
Reported
2024-09-10 11:58:58 PDT
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.
Attachments
Patch delaying matchAll and get
(18.48 KB, patch)
2024-10-29 01:47 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2024-09-10 13:08:21 PDT
<
rdar://problem/135742835
>
youenn fablet
Comment 2
2024-10-29 01:47:14 PDT
Created
attachment 473069
[details]
Patch delaying matchAll and get
youenn fablet
Comment 3
2024-10-29 03:47:03 PDT
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
Comment 4
2024-10-29 03:49:01 PDT
> (
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
Comment 5
2024-10-29 06:09:02 PDT
I filed
https://bugs.webkit.org/show_bug.cgi?id=282233
to handle the case of get.
EWS
Comment 6
2024-10-31 07:20:11 PDT
Committed
285953@main
(1c96accc39ab): <
https://commits.webkit.org/285953@main
> Reviewed commits have been landed. Closing PR #35858 and removing active labels.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug