Bug 239614 – Web Locks held in a Worker are not released on page refresh or exit

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

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.

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)

[Chris Dumez]

Thank you for the bug report, I'll investigate shortly.

[Chris Dumez]

(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.

[Radar WebKit Bug Importer]

<rdar://problem/92173575>

[Chris Dumez]

Pull request: https://github.com/WebKit/WebKit/pull/364

For a fix that wasn't "hard", it sure touched a lot of files! I appreciate the quick attention and follow-through.

[EWS]

Committed r293329 (249952@main): <https://commits.webkit.org/249952@main>

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