WebLocks: Remove invalid DCHECK and add some comments.

It is possible for a ExecutionContext to be destroyed, and all its locks
to be released while the lock is still being set up. Remove a DCHECK
that tried to verify that this didn't happen. All the relevant code
should work correctly even if Lock::handle_ does become unbound.

If the handle_ gets unbound because the ExecutionContext is destroyed
Lock might not signal LockManager that it is no longer held and thus can
be destroyed, but that is okay, as LockManager itself will clear out all
references to Lock objects when the ExecutionContext is destroyed
anyway.

Bug: 1190515
Change-Id: Idbb6014cbd7f18257fdf3f7a2dffa7f7aeae75c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2783622
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#868622}

web-locks/frames.tentative.https.html

@@ -243,4 +243,23 @@
 
 }, 'Removed Frame with pending request');
 
+promise_test(async t => {
+  assert_implements(navigator.locks);
+  const res = uniqueName(t);
+
+  const frame = await iframe('about:blank');
+
+  // Remove a frame while it is in the process of requesting a lock.
+  // The promise returned by `request` will never resolve since its frame no
+  // longer exists, but the lock should still be released.
+  await new Promise(resolve => {
+    frame.contentWindow.navigator.locks.request(res, () => {
+      frame.remove();
+      resolve();
+    });
+  });
+
+  assert_false((await navigator.locks.query()).held.includes(res));
+}, 'Removed Frame as lock is granted');
+
 </script>