[Bug 19297] May user agents apply additional restrictions on entering pointer lock?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297

Florian Bösch <pyalot@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pyalot@gmail.com

--- Comment #1 from Florian Bösch <pyalot@gmail.com> 2012-10-05 17:13:09 UTC ---
The goal of the specification should be to:

1) Provide a reliable API for developers with known behavior
2) Avoid UX issues around the usage of pointerlock insofar as the API should
not be structured to promote bad UX itself or patterns of usage by developers
that are bad UX
3) Provide safety measures impacting UX as little as possible to ensure that
malicious behavior is kept at bay.

Current implementations are currently not fulfilling #1, they are only partly
fulfilling #2 and they may or may not fulfill #3. It is my belief that a
thorough specification of the UX and Safety measures can be done, and that it
would help vendors to arrive at consistent, usable and safe implementations
without requiring them to have lengthy internal discussions about how to
restrict pointerlock culminating in pointerlock behavior that would then be
inconsistent between browsers.

Section 8 of the specification lists some use-cases which are recommended not
to be compromised such as:

- Making it possible to seamlessly switch between pointerlock and releasing it 
- Making it possible to request pointerlock without requiring fullscreen at the
same time
- Making it possible for iframes to request pointerlock.

An issue with current implementations is the requirement for fullscreen by one
vendor in the form of only regarding pointerlock requests soonest in the
fullscreenchange event, while another vendor does not impose such a
restriction, yet does restrict requestPointerLock only to user interaction
events. This is particularly bad since we are not dealing with differing APIs,
but entirely differing behavior, that stands no hope of being wrapped,
abstracted, monkey patched or otherwise glanced over. The abstraction of these
decisions will fully leak trough to user-code.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 5 October 2012 17:13:11 UTC