Bug 239614 - Web Locks held in a Worker are not released on page refresh or exit
Summary: Web Locks held in a Worker are not released on page refresh or exit
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: Safari Technology Preview
Hardware: Mac (Intel) macOS 12
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-04-21 10:39 PDT by apple-rth
Modified: 2022-04-25 09:11 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description apple-rth 2022-04-21 10:39:53 PDT
There is a test page at this link:
https://rhashimoto.github.io/web-locks-test/

1. Open the test page in Safari or Safari Technology Preview.
2. Refresh the page a few times.

The expected output (which is shown by Chrome and Firefox) should always be this:

{
  "held": [],
  "pending": []
}
lock acquired from window
lock acquired from worker

On Safari, the expected output is shown on the first page load, but on subsequent loads, it shows held and pending locks for "worker-lock" and the lock is *not* acquired from the worker.


Here's what the page does:

Using the Web Locks API, my test page collects lock status (with navigator.locks.query) and then acquires a lock like this from both the Window context and a Worker context:

navigator.locks.request('worker-lock', function() {
  postMessage('lock acquired from worker');

  return new Promise(resolve => {
    // Don't release the lock.
  });
});

By returning an unresolved Promise from the request callback, this holds an exclusive lock indefinitely. I know that real code would have a means to release the lock; this is just to demonstrate the problem.

I expect when the contexts are exited, e.g. by refreshing the page, that the lock will be released and so will be available the next time the page starts. This is true for all other browsers I have tried, but on Safari, this is the case for the Window context but not for the Worker context.

This has the potential to cause deadlock in any application that uses Web Locks in a Worker. The only way I have found for a user to recover is to restart Safari.
Comment 1 apple-rth 2022-04-21 10:50:47 PDT
macOS Version 12.3.1 (21E258)
Safari Version 15.4 (17613.1.17.1.13)
Safari Technology Preview Release 143 (Safari 15.4, WebKit 17614.1.7.7)
Comment 2 Chris Dumez 2022-04-22 08:18:41 PDT
Thank you for the bug report, I'll investigate shortly.
Comment 3 Chris Dumez 2022-04-22 10:14:51 PDT
(In reply to Chris Dumez from comment #2)
> Thank you for the bug report, I'll investigate shortly.

I can reproduce, thank you for the test case. Shouldn't be hard to fix.
Comment 4 Radar WebKit Bug Importer 2022-04-22 10:15:12 PDT
<rdar://problem/92173575>
Comment 5 Chris Dumez 2022-04-22 15:31:13 PDT
Pull request: https://github.com/WebKit/WebKit/pull/364
Comment 6 apple-rth 2022-04-23 11:12:06 PDT
For a fix that wasn't "hard", it sure touched a lot of files! I appreciate the quick attention and follow-through.
Comment 7 EWS 2022-04-25 09:11:52 PDT
Committed r293329 (249952@main): <https://commits.webkit.org/249952@main>

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