Security/Reviews/Mouse-Pointer Lock

Please use "Edit with form" above to edit this page.

Item Reviewed

Extend Pointer Lock (Mouse Lock) for non-fullscreen elements
Target	* multiple monitors lose fullscreen on focus change video full screen in one monitor and work on something else on the other or have 2 monitors have different things full screen Current plan is to show the full-screen warning again for 4 seconds whenever a full-screen page regains focus.

{{#set:SecReview name=Extend Pointer Lock (Mouse Lock) for non-fullscreen elements |SecReview target=* multiple monitors lose fullscreen on focus change

• • video full screen in one monitor and work on something else on the other
  • or have 2 monitors have different things full screen
  • Current plan is to show the full-screen warning again for 4 seconds whenever a full-screen page regains focus.

}}

Introduce the Feature

Mac Spaces questions

• Will this allow you to use multiple spaces on a single monitor? (With one in full-screen mode and another showing another app, or another Firefox tab)
  • Probably? might need to ask zpao.
• With multiple monitors, mac's concept of spaces and full-screen tends to affect all monitors at once :/

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

• Showing the warning again for 4 seconds upon return seems like overkill.
  • How about just one second?
  • How about a smaller warning? (Perhaps a watermark, if we can make it hard to hide)

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

• The "warning when switching between two full-screen windows" might be defeatable, when a single site is full-screen in both windows (immersive demos and games)
  • What if a web page lies about where focus is?
    • It can't prevent mouse clicks
      • Lies about where the mouse cursor is?
  • This isn't really worse than the situation with one full-screen window
• 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====Mac Spaces questions===

• Will this allow you to use multiple spaces on a single monitor? (With one in full-screen mode and another showing another app, or another Firefox tab)
  • Probably? might need to ask zpao.
• With multiple monitors, mac's concept of spaces and full-screen tends to affect all monitors at once :/

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

• Showing the warning again for 4 seconds upon return seems like overkill.
  • How about just one second?
  • How about a smaller warning? (Perhaps a watermark, if we can make it hard to hide)

|SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=' |SecReview threat brainstorming=* The "warning when switching between two full-screen windows" might be defeatable, when a single site is full-screen in both windows (immersive demos and games)

• • What if a web page lies about where focus is?
    • It can't prevent mouse clicks
      • Lies about where the mouse cursor is?
  • This isn't really worse than the situation with one full-screen window
• 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.

}}