Can't get pointer lock for elements inside ShadowRoots.
Reported by
bickne...@gmail.com,
May 13 2018
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3428.0 Safari/537.36 Steps to reproduce the problem: 1. Create an element A inside another element B's ShadowRoot. 2. Call `requestPointerLock` on A. 3. Read `document.pointerLockElement` after the "pointerlockchange" event or listen for mouse events on A. What is the expected behavior? `document.pointerLockElement` should be the element inside the ShadowRoot (A) and mouse events should be dispatched to that element. What went wrong? `document.pointerLockElement` is the element with the ShadowRoot (B) and events are instead dispatched to it. Did this work before? N/A Does this work in other browsers? No Safari is also incorrect in the same way. Chrome version: 68.0.3428.0 Channel: n/a OS Version: OS X 10.13.4 Flash Version: The attached file includes a case that attempts to pointer lock an element which is multiple levels deep within ShadowRoots. In this case, the locked element becomes the host of the outermost ShadowRoot. I'm guessing that the pointer lock code is not aware of Shadow DOM and might be using some native equivalent to `event.target`, which is retargeted for ShadowRoots, rather than something more like `event.composedPath()[0]`.
,
May 15 2018
Thanks for filing the issue! Tested the issue on chrome reported version 68.0.3428.0 using Mac 10.12.6 using with steps mentioned below: 1) Launched chrome reported version, dragged and dropped the file provided in comment# 0 2) Please find the attached for the behaviour of the .html file @Reporter: Please find the attached screenshot for your reference, if possible could you please provide screenshot of the excepted behaviour of the issue which help in better understanding and further triaging it. Thanks!
,
May 17 2018
Reporter I believe this behavior is by design. You can also take a look at the spec: https://w3c.github.io/pointerlock/#dom-documentorshadowroot-pointerlockelement which has a similar example. Essentially the outer document should not see the inner nodes of the shadow root by default. So it only sees the host as the locked element. Let me know if you agree with this explanation.
,
May 17 2018
Oh, yup, I totally missed that `pointerLockElement` was part of `DocumentOrShadowRoot` and not just `Document`! After updating the demo to use `element.getRootNode().pointerLockElement` to find the locked element, this seems to work as expected and Shadow DOM seems to be appropriately accounted for in the spec. Thank you all for investigating!
,
May 18 2018
Work as intended. |
||||
►
Sign in to add a comment |
||||
Comment 1 by krajshree@chromium.org
, May 14 2018