MozillaWiki

Security/Reviews/Mouse-Pointer Lock

< Security‎ | Reviews
Please use "Edit with form" above to edit this page.

Item Reviewed

Extend Pointer Lock (Mouse Lock) for non-fullscreen elements
Target 
   
     Full Query
ID Summary Priority Status
822654 SecReview: Extend Pointer Lock (Mouse Lock) for non-fullscreen elements -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

{{#set:SecReview name=Extend Pointer Lock (Mouse Lock) for non-fullscreen elements

|SecReview target=

Full Query
ID Summary Priority Status
822654 SecReview: Extend Pointer Lock (Mouse Lock) for non-fullscreen elements -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

What solutions/approaches were considered other than the proposed solution?

Why was this solution chosen?

Any security threats already considered in the design and why?

`

Threat Brainstorming

  • How do we communicate the question of whether to allow pointer lock? The phrase "pointer lock" doesn't really convey the concept, even to users who have seen games use it.
    • Chrome says "Disable your mouse cursor"
    • "Use your mouse to control something other than your cursor"
  • Can users always use Esc to get out?
  • What happens if you're in pointer lock and you switch apps or switch tabs?
  • What happens to trackpad multi-touch or gestures (scroll, pinch, etc)
    • We already have a touch API?
  • What happens on devices that have both touch and mouse?
    • If you touch outside the content area, you're probably taking focus away, so it will probably disable content lock?
  • What effect does it have on touch-only devices?
    • Maybe we should tell the page it was denied? A game that wants to support touch will need to listen for touch events.

{{#set: SecReview feature goal=* Allow pointer lock when not in full screen mode ( https://bugzilla.mozilla.org/show_bug.cgi?id=822654 and https://wiki.mozilla.org/Security/Reviews/Mouse-Pointer_Lock )

  • Current plan: in response to a click, a web page may activate a doorhanger "Do you want to allow this site to go into pointer-lock mode?"
    • Note that pointer lock comes free with full-screen. Full-screen asks for forgiveness while pointer-lock-alone asks for permission.
  • Keeping the existing model for pointer lock during full-screen.

|SecReview alt solutions= |SecReview solution chosen= |SecReview threats considered=' |SecReview threat brainstorming=* How do we communicate the question of whether to allow pointer lock? The phrase "pointer lock" doesn't really convey the concept, even to users who have seen games use it.

    • Chrome says "Disable your mouse cursor"
    • "Use your mouse to control something other than your cursor"
  • Can users always use Esc to get out?
  • What happens if you're in pointer lock and you switch apps or switch tabs?
  • What happens to trackpad multi-touch or gestures (scroll, pinch, etc)
    • We already have a touch API?
  • What happens on devices that have both touch and mouse?
    • If you touch outside the content area, you're probably taking focus away, so it will probably disable content lock?
  • What effect does it have on touch-only devices?
    • Maybe we should tell the page it was denied? A game that wants to support touch will need to listen for touch events.

}}

Action Items

Action Item Status In Progress
Release Target `
Action Items
* Can we make sure that Esc (and cursor keys) cannot be used as a "user-triggered event handler" for the purpose of opening popups etc? Or maybe only a whitelist of keycodes / charcodes (space, enter, printable characters) https://bugzilla.mozilla.org/show_bug.cgi?id=748198
    • This will break the Doom case of "Esc opens the menu and releases pointer lock; Esc again closes the menu and regains pointer lock". Games like that will have to use a different keybinding for their in-game menu with a fake cursor, or put an item on the menu for resuming the game. (Just like a full-screen game has to use a key other than Esc for its menu.)
  • [mwobensmith?] Test what happens when you have a device with both touch and cursor.

{{#set:|SecReview action item status=In Progress

|Feature version=` |SecReview action items=* Can we make sure that Esc (and cursor keys) cannot be used as a "user-triggered event handler" for the purpose of opening popups etc? Or maybe only a whitelist of keycodes / charcodes (space, enter, printable characters) https://bugzilla.mozilla.org/show_bug.cgi?id=748198

    • This will break the Doom case of "Esc opens the menu and releases pointer lock; Esc again closes the menu and regains pointer lock". Games like that will have to use a different keybinding for their in-game menu with a fake cursor, or put an item on the menu for resuming the game. (Just like a full-screen game has to use a key other than Esc for its menu.)
  • [mwobensmith?] Test what happens when you have a device with both touch and cursor.

}}

Retrieved from "https://wiki.allizom.org/index.php?title=Security/Reviews/Mouse-Pointer_Lock&oldid=530473"