Security/Reviews/Mouse-Pointer Lock: Difference between revisions
No edit summary |
No edit summary |
||
Line 7: | Line 7: | ||
</bugzilla> | </bugzilla> | ||
}} | }} | ||
{{SecReview | |||
|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 ) | * 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 alt solutions= | |||
== | |SecReview solution chosen= | ||
* 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. | |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" | ** Chrome says "Disable your mouse cursor" | ||
** "Use your mouse to control something other than your cursor" | ** "Use your mouse to control something other than your cursor" |
Revision as of 19:30, 26 February 2013
Item Reviewed
Extend Pointer Lock (Mouse Lock) for non-fullscreen elements | |||||||||
Target |
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=
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%);
}} {{SecReview |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 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
|
{{#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.
}}