Security/Reviews/Mouse-Pointer Lock: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
{{SecReviewInfo
{{SecReviewInfo
|SecReview name=Extend Pointer Lock (Mouse Lock) for non-fullscreen elements
|SecReview name=Extend Pointer Lock (Mouse Lock) for non-fullscreen elements
|SecReview target=* multiple monitors lose fullscreen on focus change
|SecReview target=<bugzilla>
** video full screen in one monitor and work on something else on the other
{
** or have 2 monitors have different things full screen
"id":"822654"
** Current plan is to show the full-screen warning again for 4 seconds whenever a full-screen page regains focus.
}
</bugzilla>
}}
 
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) ===
* 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 )
* 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?"
* 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.
** 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.
* Keeping the existing model for pointer lock during full-screen.
}}
 
{{SecReview
== Threat Brainstorming ==
|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 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.
* 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"
** Chrome says "Disable your mouse cursor"
Line 35: Line 26:
* What effect does it have on touch-only devices?
* 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.
** Maybe we should tell the page it was denied? A game that wants to support touch will need to listen for touch events.
}}
 
{{SecReviewActionStatus
{{SecReviewActionStatus
|SecReview action item status=In Progress
|SecReview action item status=In Progress

Revision as of 19:16, 26 February 2013

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%);

}}

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

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.

}}