997528 - Capture Escape in Fullscreen mode

Status: NEW

(Firefox :: General, defect)

Description

[Louis Stowasser [:louisstow]]

Escape is a common key to hit in fullscreen mode and breaks immersion. Should have a more difficult combination and be able to capture it before exiting for custom handling.

Comment 1

[:Gijs (he/him)]

I don't think "forcing fullscreen mode to stay on" is something we should let the web do, lest it be used for nefarious ends (like many "innocuous" things like alert and onbeforeunload already are).

Comment 2

[Martin Best (:mbest)]

This is something that has been requested, but I don't think we should do this change.  The esc key is one of the few keys that users will try if confused about how to get out of fullscreen mode will naturally try.  As long as their is an exit full screen event passed to the web page, that's about the extent of what we can provide them in the way of getting the esc key.  I'm recommend we close this bug as won't fix.

Comment 3

[Ian Langworth]

Could this functionality be behind an internal setting? The reasoning would be that power users for games are savvy enough to tweak their settings to get an optimal experience.

Comment 4

[Martin Best (:mbest)]

I don't think that will improve the situation.  The vast majority of users will not flip the flag and game developers will still have to work around the 'esc' fullscreen/menu conflict in their designs to accommodate the majority.  At worst this would give game developers false hope that this paradigm would become default one day and make them hesitate adapting.

My resistance is purely due to not being clever enough to think of a good alternative.  If someone can suggest a workable design that has both the 'esc' key override available by default to any developer that wants it, I'd be very open to learn more.  The primary concern that the design must address is to minimize the risk that a to less savvy users getting stuck in fullscreen mode due to a more obscure exit method.

I've been giving this a fair amount of thought in the last few days and haven't come up with anything that seems like a good alternative.

Comment 5

[Mark Logan]

1. Let's not be too quick to discard the idea of putting this behind an internal setting (e.g. "[√] Use F11 to exit fullscreen instead of escape"). If it's truly the only possible way to solve this problem, it's a lot better than nothing, from our perspective. An easy-to-accidentally-hit key that exits fullscreen is a complete show-stopper for us.

2. Can the risk to non-savvy users be addressed by having a different, scarier, possibly multi-step permission dialog?

Lastly, Martin, can you say more about what you meant by this?: "If someone can suggest a workable design that has both the 'esc' key override available by default to any developer that wants it, I'd be very open to learn more." I couldn't quite understand what you meant.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hitting Escape while in non-fullscreen allows the app to intercept Esc.  Hitting Esc while in fullscreen leaves fullscreen mode, and crucially, notifies the app via an event that this happened.

This seems to be sufficient to implement a config menu/pause menu/etc. -- you can just do it while the app is not full screen.  The only time this wouldn't work is if Esc is part of gameplay itself (e.g. if it's used to back out of, I dunno, store menus or character sheets).  But that can be handled by tweaking that mechanic itself.  But if the core issue is that it's too easy to exit fullscreen, that's trickier, since that's sort of by design.

I don't disagree that having an easy to hit key exit fullscreen is bad, but is Esc really that easy to hit?  (Fully willing to accept that it is; certainly easier than alt-enter or similar.)  I think this would be a very difficult change to push, especially to other browsers

*However*, this is something that we should throw into the bucket of "some apps are more special than others"; or rather, some apps the user may want to choose to have a closer relationship/integration with.  We've kicked this idea around for a while, but never figured out how to actually do it so it makes sense, or so that it doesn't harm other apps.  Basically, a way to have apps request some additional set of not-security-sensitive permissions and capabilities; generally things that will allow them to offer a more immersive or cleaner user experience, at the expense of losing common UI feature sets with regular web pages.  We should really revisit this.

Comment 7

[Mark Logan]

"is Esc really that easy to hit?"

For our game, yes it is. Our game is an RTS, similar in play-style to StarCraft. Intermediate and higher players (at least the right-handed ones) typically play such games with the right hand on the mouse, and the left hand above the left side of the keyboard. The number keys, letter keys, function keys, and the ~ and TAB keys are heavily used to quickly activate abilities and select different combinations of units on screen. Even if we choose not to use the escape key for anything, you can see that it is surrounded by useful (and heavily-used) keys, and will eventually get hit by accident - and usually at the worst possible time (in the middle of a frantic battle when the player is too panicked to be careful about not hitting a stray key). This has been a recurring problem for our play-testers.

Comment 8

[Thibaut Despoulain]

Attachment: FSproposal.png

Here's a proposal that might be a good compromise.
Thoughts?

Comment 9

[Justin Dolske [:Dolske]]

(In reply to Mark Logan from comment #5)
> 1. Let's not be too quick to discard the idea of putting this behind an
> internal setting (e.g. "[√] Use F11 to exit fullscreen instead of escape").
> If it's truly the only possible way to solve this problem, it's a lot better
> than nothing, from our perspective. An easy-to-accidentally-hit key that
> exits fullscreen is a complete show-stopper for us.

Prefs like these are generally a bad idea / avenue of last-resort.  A solution that works for most users and is easily discoverable would be much preferred, since tons of people never even go looking for ways to change defaults (and thus would keep running into the problem even though it's "fixed").


(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #6)

> But if the core issue is that
> it's too easy to exit fullscreen, that's trickier, since that's sort of by
> design.

Indeed. ESC-to-exit is the defacto way to exit full-screen in many apps. And consider that this same API needs to deal with other use cases like video players and getting out of abusive sites.

Attachment 8411272 [details] is an interesting idea, but makes video players really awkward to use. (Double-tap instead of press-and-hold would be better, but I don't know if that adequately fixes the problem this bug is about, and is still a change to a standard UX) It's also fair to criticize it from a different angle, in that if you're in the middle of an immersive experience and get random messages like this from the browser, that kind of sucks. :)

We could put some kind of greater control behind a permission prompt, but prompts for technical things like this often end up being hard/awkward to explain. Especially when you factor in that a lot of people only skim these as "whatever prompts".

I don't any great suggestions, though. :( Best I can think of at the moment is an API to request a harder-to-exit FS mode (which games would use, but video players would not), and have the browser use some heuristics to figure out if the press is an accident or not. A little user research might be helpful -- eg, will users mash ESC repeatedly if a misbehaving page is trying to keep them in FS mode? And can we reliably detect that to differentiate intent, without appearing to randomly be broken?

> *However*, this is something that we should throw into the bucket of "some
> apps are more special than others"; or rather, some apps the user may want
> to choose to have a closer relationship/integration with.  We've kicked this
> idea around for a while, but never figured out how to actually do it so it
> makes sense, or so that it doesn't harm other apps. 

Right, usually this has come up in the context of pinned browser tabs. The rationale being that pinned sites are probably things you use/trust more than a randomly visited page, so it's less likely to be malicious. I dunno if that helps here, though. Standalone webapps would be different matter.