This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26934 - [Shadow]: How should Element.requestPointerLock() work in shadow DOM?
Summary: [Shadow]: How should Element.requestPointerLock() work in shadow DOM?
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 26365
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-29 23:47 UTC by Olli Pettay
Modified: 2015-07-06 08:17 UTC (History)
3 users (show)

See Also:


Attachments

Description Olli Pettay 2014-09-29 23:47:53 UTC
Currently requestPointerLock requires element to be in Document, but Chromium
does let one to lock pointer to a shadow dom element too.
Comment 1 scheib 2014-09-30 15:38:41 UTC
There's nothing fundamentally wrong with pointer lock targeting any element. Specifying the element must be in the document easily handles any kind of navigation concerns (where lock must be released) and dismiss any open ended questions about where events are headed if elements aren't in the document.

Here are the relevant sections of Pointer Lock:

"""
5.1 Methods

requestPointerLock

...

Pointer lock must succeed only if the target is in the active document of a browsing context which is (or has an ancestor browsing context which is) in focus by a window which is in focus by the operating system's window manager. 

...

8 Requirements

Pointer lock must be exited if the target is removed from its document, or the user agent, window, or tab loses focus. Moving focus between elements of active documents, including between browsing contexts, does not exit pointer lock. E.g. using the keyboard to move focus between contents of frames or iframes will not exit.
"""


And here is a draft of a change to add shadow tree/host to the sections:

"""
5.1 Methods

requestPointerLock

...

Pointer lock must succeed only if the target is in the active document (or a shadow tree of a shadow host in the active document) of a browsing context which is (or has an ancestor browsing context which is) in focus by a window which is in focus by the operating system's window manager. 

...

8 Requirements

Pointer lock must be exited if any of the follow occur:
- The target is removed from its document.
- The target is removed from its shadow tree.
- The user agent, window, or tab loses focus.
Moving focus between elements of active documents, including between browsing contexts, does not exit pointer lock. E.g. using the keyboard to move focus between contents of frames or iframes will not exit.
"""

Review & comments please.
Comment 2 Olli Pettay 2014-09-30 15:49:09 UTC
> 5.1 Methods
> 
> requestPointerLock
> 
> ...
> 
> Pointer lock must succeed only if the target is in the active document (or a
> shadow tree of a shadow host in the active document)
We probably don't want elements in older shadow trees which aren't projected to newer shadow trees to
be able to lock the pointer.
Comment 3 Hayato Ito 2015-07-06 08:17:09 UTC
Moved to https://github.com/w3c/webcomponents/issues/192