Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

context should have access to the locked element. #30

Closed
vmpstr opened this issue Nov 14, 2018 · 1 comment
Closed

context should have access to the locked element. #30

vmpstr opened this issue Nov 14, 2018 · 1 comment

Comments

@vmpstr
Copy link
Collaborator

vmpstr commented Nov 14, 2018

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?

@chrishtr
Copy link
Collaborator

Seems reasonable to me to put in the API.

aarongable pushed a commit to chromium/chromium that referenced this issue Nov 16, 2018
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}
@vmpstr vmpstr closed this as completed Nov 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants