W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Pointer lock updated with clarification of lock and focus requirements.

From: Vincent Scheib <scheib@google.com>
Date: Mon, 18 Mar 2013 10:28:39 -0700
Message-ID: <CAK-EfXkcJzZWBamKxBTL0MtTiQySriXVDeHefUkJjZ9hj4TOBg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Webapps WG <public-webapps@w3.org>, Olli Pettay <Olli.Pettay@helsinki.fi>
On Sat, Mar 16, 2013 at 7:51 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Mar 15, 2013 at 5:24 PM, Vincent Scheib <scheib@google.com> wrote:
>> After discussion with Olli Pettay I have clarified portions of the
>> pointer lock specification.
>> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
>> https://dvcs.w3.org/hg/pointerlock/diff/6543d83c0b74/index.html
>> When requesting pointer lock, this paragraph replaces previous statements
>> regarding the target being in the DOM tree.
>> """
>> 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. The target element and its browsing context need not be in focus.
>> """
>> In Requirements, clarification was added that focus MAY be shifted out of
>> a document and into others without exiting lock:
>> """
>> The Pointer Lock API must exit the pointer lock state 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.
>> """
>> Feedback and suggestions welcome.
> Why would pointer lock care about focus?

Multiple browser contexts may be displayed in one window by a browser, and
in most browsers pressing TAB key will move between focusable elements,
such as buttons, including across browsing contexts (e.g. crossing iframe
boundaries). The spec was updated the explicitly clarify that pointer lock
does not care about this focus across browsing contexts.

> If the browsing context doesn't have focus, pointer lock may be released
> at the system level, but that should be transparent to the page and
> reestablished automatically if the user returns.

The property of the user agent exiting pointer lock when the window looses
focus is intentionally included in the specification to increase the
ability of a user to exit pointer lock and return to the browser without
being forced back into lock. They can navigate away from a page without the
page able to re-capture the pointer. This is why a user gesture is required
for re-entry. This will be clarified when I close
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297 pending Mozilla's
implementation of https://bugzilla.mozilla.org/show_bug.cgi?id=737100#c5.

> Pages shouldn't need to care about this.
> This is the same as fullscreen--obviously a page shouldn't be forced out
> of fullscreen if the user switches to another tab or application, unless
> that's the system convention (which it isn't on any platform I know of).
> (By the way, if a web specification finds itself talking about "windows"
> or "window managers" or "tabs" normatively, something is probably wrong.
> Interfaces at a higher abstraction level than browsing contexts are
> implementation details.  Please see
> http://www.whatwg.org/specs/web-apps/current-work/#dom-document-hasfocusfor platform-independent language.)

Hasfocus relates to the document. I suppose I can re-word to something
like, "all documents of all active browsing contexts which
are descendants of the top most browsing context do not have focus" instead
of "user agent tab or window loses focus". :\ yuck.

> --
> Glenn Maynard
Received on Monday, 18 March 2013 17:29:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:59 UTC