Re: [webcomponents] Shadow DOM and requestPointerLock() (#192)

OK, so the goal is that when a shadow node acquires lock the light tree should be ignorant.

Then I would suggest 

- Relocking without requiring a user gesture should only work from within the same tree. See 5.1 with text: "If a user has exited pointer lock via the default unlock user gesture, or pointer lock has not previously been entered for this document...". That logic is intended for script code to exit and re-enter lock state - but it doesn't make sense for that logic to cross a shadow tree boundary.
- When locked, no mouse event of any kind should be dispatched, or bubbled, to the light DOM.
- When locked to a light or shadow tree A a subsequent lock to a node in a different light or shadow tree B should be blocked, similar to text in `requestPointerLock`

> If any element in another document is already locked the request must fail and a pointerlockerror event be sent.


I don't fully understand the shadow tree document structure. Does each tree have a document, or is the document a mix of trees? Presuming the later, these are needed:

- `shadowRoot.pointerlockElement` so that the shadow node can use the element, while light DOM is not affected. 
- `shadowRoot.onpointerlockchange` and `shadowRoot.onpointerlockerror` would also be needed to be hidden in shadowRoot
- `shadowRoot.exitPointerLock` should only work for a lock in the currently locked tree.

I don't think changes are needed for:

- movementX/Y. So long as no events are reached by the light tree there will be no opportunity to read those values.
- light tree 'enabling' the feature, similar to iframe (see 5.1 requestPointerLock active sandboxing flag)



---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/192#issuecomment-200093081