Pref on by default exiting of fullscreen on escape key event on macOS
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox94 | --- | verified |
People
(Reporter: spohl, Assigned: spohl)
References
Details
Attachments
(1 file)
Having analyzed all reports received so far regarding broken behavior and workflows due to our exiting fullscreen when pressing the escape key on macOS, it looks like we are left with "just" websites failing to call preventDefault when handling the escape key. We have accepted this as an unfortunate consequence of enabling this feature and are going to turn this back on by default. However, unlike the first time that this feature was turned on by default, affected users will now be able to revert to the previous behavior by flipping the browser.fullscreen.exit_on_escape back to false.
|
Assignee | |
Comment 1•3 years ago
|
||
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
Pushed by spohl@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7b44a5ea3467 Turn on by default exiting of fullscreen on escape key press on macOS. r=mstange
|
||
Comment 3•3 years ago
|
||
| bugherder | ||
|
||
Comment 4•3 years ago
|
||
Verified that browser.fullscreen.exit_on_escape is set on true by default with Firefox 94.0a1 (20210926210158) on macOS 10.15 and macOS 11 ARM.
|
||
Comment 5•2 years ago
|
||
As others have stated, in other bugs (see #1726810 for one example), my daily workflow has suffered from this change. I have regularly found the browser window exiting full-screen mode, taking me out of flow, and forcing me to perform window-management tasks and losing the context of what I was working on.
It's quite frustrating to have such a change implemented without any warning in the standard UI indicating that it was made, nor note of how to revert to the previous behavior. Thankfully there is a switch in about:config, but this is certainly not very visible to the average user. I finally found the option by searching through Bugzilla.
Is it reasonable to believe that an average user should have to go through that much trouble to regain previously default behavior from a breaking change (and yes, breaking user workflow is a breaking change when the sole goal of application in question is to enable the user to interface with other applications)? At the very least, I would have hoped to have seen an entry in the standard Settings menu. Some indication of the change after the update would have been a significant additional improvement.
Lastly, the edge cases which caused the original return to the default "off" behavior for this feature are still lingering. One currently reproducible example of unexpected behavior is with the new command palette in Github:
Steps to reproduce:
- Navigate to https://github.com
- Enable the Command Palette (https://docs.github.com/en/get-started/using-github/github-command-palette) feature preview.
- Press ⌘+k
- Wait for the modal to open.
- Press the ESC key.
Expected behavior:
The command palette exits.
Actual behavior:
The command palette exits.
The browser exits full-screen mode.
|
|
Assignee | |
Comment 6•2 years ago
|
||
(In reply to Brian Shacklett from comment #5)
Lastly, the edge cases which caused the original return to the default "off" behavior for this feature are still lingering. One currently reproducible example of unexpected behavior is with the new command palette in Github:
This is an example of a website/feature that does not call preventDefault() on the key event. Safari exhibits the same "broken" behavior. Since the command palette is in beta, it is a perfect opportunity to report this against the command palette and hopefully get it fixed before official release.
Description
•