You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.
Particularly in lock-before-append mode, it seems to always be necessary to have access to the locked element, and this pattern is probably very likely:
The locked element attribute is useful on the context since it creates
an easy access point to add elements into.
R=chrishtr@chromium.org
Bug: WICG/display-locking#30
Change-Id: I726a1db72373bdde261a808b38ccb17424a21348
Reviewed-on: https://chromium-review.googlesource.com/c/1336507
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: vmpstr <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608792}
Particularly in lock-before-append mode, it seems to always be necessary to have access to the locked element, and this pattern is probably very likely:
e.acquireDisplayLock((context) => { func(context, e); });
Maybe |context| should have a lockedElement member so that one can write:
e.acquireDisplayLock(func);
And then context.lockedElement.appendChild(...); or whatever else is needed.
WDYT?
The text was updated successfully, but these errors were encountered: