Security/Reviews/Mouse-Pointer Lock: Difference between revisions
No edit summary |
No edit summary |
||
Line 5: | Line 5: | ||
** or have 2 monitors have different things full screen | ** 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. | ** Current plan is to show the full-screen warning again for 4 seconds whenever a full-screen page regains focus. | ||
* 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 | {{SecReview | ||
Line 37: | Line 41: | ||
** 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.) | ** 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. | * [mwobensmith?] Test what happens when you have a device with both touch and cursor. | ||
}} | }} |
Revision as of 15:02, 26 February 2013
Item Reviewed
Extend Pointer Lock (Mouse Lock) for non-fullscreen elements | |
Target | * multiple monitors lose fullscreen on focus change
|
{{#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.
- 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.
}}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
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?
- It can't prevent mouse clicks
- This isn't really worse than the situation with one full-screen window
- What if a web page lies about where focus is?
- 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?
- It can't prevent mouse clicks
- This isn't really worse than the situation with one full-screen window
- What if a web page lies about where focus is?
- 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.
}}