Fullscreen Keyboard Lock does not intercept ctrl+tab and keyboard events dispatched to chrome listeners
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
People
(Reporter: intelfx, Assigned: sfarre)
References
Details
Attachments
(4 files, 2 obsolete files)
Demo of Chromium intercepting OS shortcuts with a permission dialog
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:152.0) Gecko/20100101 Firefox/152.0
Steps to reproduce:
- Implemented a minimal test for Fullscreen Keyboard Lock API (Bug 700123):
<html>
<script>
function foo() {
let b = document.getElementById("go");
b.addEventListener("mouseup", function() {
let d = document.getElementById("dump");
d.requestFullscreen({"keyboardLock": "browser"}).then(function() {
let handler = function(name, ev) {
ev.preventDefault();
d.innerText += `${name}: ${ev.code}\n`;
};
let b = document.getElementById("body");
b.addEventListener("keyup", (ev) => handler("keyup", ev));
b.addEventListener("keydown", (ev) => handler("keydown", ev));
});
});
}
</script>
<body id="body" onload="foo()">
<button id="go">Go fullscreen</button>
<div id="dump">Press the button ^^^ and try some hotkeys</div>
</body>
</html>
Actual results:
Web application does not receive key combinations such as Alt-Tab/Meta-Tab (passed through to the OS compositor) or Ctrl-Tab (switches tabs in the browser).
Expected results:
-
at least, Ctrl-Tab (browser-level key combination, handled within Firefox for tab switching) should be interceptable always;
-
at most, Alt-Tab/Meta-Tab (system-level key combinations, typically handled in the OS windowing system/compositor) should be interceptable, pending permission from the user.
All three key combinations are supported (i.e. interceptable) in Chromium.
|
Reporter | |
Comment 1•2 months ago
|
||
The specific use-case for supporting these key combinations is for remote control, such as a Web UI for an IP-KVM, which we are developing. The Web UI presents a full-screen view of a remote desktop. When interacting with such a full-screen view of a remote desktop (e.g., with a web browser opened on the remote end), the user expectation is that all keys (including window or tab management keys) are forwarded to the remote host being controlled (which is what appears on screen), rather than affect the local machine (whose UI is not visible at all).
|
|
Reporter | |
Updated•2 months ago
|
|
||
Comment 2•2 months ago
|
||
|
Assignee | |
Comment 3•2 months ago
|
||
When keyboard lock is enabled, don't preventDefault
ctrl+tab/ctrl+shift+tab and don't run the normal behavior either, as
this will change tabs and take us out of fullscreen.
|
||
Updated•2 months ago
|
|
|
||
Comment 4•2 months ago
|
||
I think we can allow ctrl-tab to be intercepted, or even make it not switch tabs by default while in fullscreen keyboard lock (which is what happens in Safari and Chrome).
Safari and Chrome don't allow cmd+tab to be intercepted on macOS. Chrome apparently allows it on Linux. I understand the remote desktop use case, but it needs to be balanced against user security for hostile web content. As for user permission, it seems it was tried and decided against in Chrome, see https://developer.chrome.com/blog/keyboard-lock-pointer-lock-permission
For now, I think we shouldn't allow OS app switching shortcuts to be intercepted on any platform. Remote desktop like apps can use ctrl+tab or so instead.
|
||
Updated•2 months ago
|
|
|
Assignee | |
Comment 5•2 months ago
|
||
This adds a flag to the event, that prevents it from being fired to
mozSystemGroup listeners if keybboard lock is enabled.
|
|
Assignee | |
Comment 6•2 months ago
|
||
As per discussion on slack with :kagami the second patch probably is more future proof, given that it doesn't let UI potentially capture and e.preventDefault() keyboard events.
|
|
||
Comment 7•2 months ago
|
||
Simon - once we're good with the scope, please refine the bug title to make it more specific, which will help future tracking. Thanks.
|
|
Assignee | |
Updated•2 months ago
|
|
|
||
Updated•2 months ago
|
|
||
Updated•2 months ago
|
|
|
Assignee | |
Comment 8•2 months ago
|
||
This gives content a chance to always deal with the input before chrome.
|
|
||
Updated•2 months ago
|
|
|
Reporter | |
Comment 9•2 months ago
|
||
(In reply to Simon Pieters [:zcorpan] from comment #4)
I think we can allow ctrl-tab to be intercepted, or even make it not switch tabs by default while in fullscreen keyboard lock (which is what happens in Safari and Chrome).
Safari and Chrome don't allow cmd+tab to be intercepted on macOS. Chrome apparently allows it on Linux. I understand the remote desktop use case, but it needs to be balanced against user security for hostile web content. As for user permission, it seems it was tried and decided against in Chrome, see https://developer.chrome.com/blog/keyboard-lock-pointer-lock-permission
For now, I think we shouldn't allow OS app switching shortcuts to be intercepted on any platform. Remote desktop like apps can use ctrl+tab or so instead.
I don't think that's right. At least on GNOME/Wayland, Chromium does intercept OS-level key combinations, via the user permission request. As far as I undestand, this happens via the keyboard-shortcuts-inhibit-unstable-v1 protocol and subsequently GNOME Shell requesting the user permission.
I believe this should be considered a Chrome feature parity issue, as this would be highly relevant for the remote-desktop use case (and subsequently steer users of such products away from Firefox, as it happens right now).
|
|
||
Updated•2 months ago
|
|
|
||
Updated•2 months ago
|
|
||
Comment 10•2 months ago
|
||
The bug is marked as tracked for firefox151 (beta). However, the bug still has low severity.
:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
|
|
||
Comment 11•2 months ago
|
||
It's a shipping blocker for a new feature, which doesn't and shouldn't cause impact in the wild when the feature is released. S3 is right.
|
||
Comment 12•2 months ago
|
||
|
||
Comment 13•2 months ago
|
||
| bugherder | ||
|
|
||
Comment 14•2 months ago
|
||
Please add a beta uplift request
|
|
||
Comment 15•2 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined/Reason for urgency: Keyboard lock will break if user presses ctrl+tab.
- Code covered by automated testing?: yes
- Fix verified in Nightly?: yes
- Needs manual QE testing?: no
- Steps to reproduce for manual QE testing:
- Risk associated with taking this patch: low
- Explanation of risk level: New behavior only triggered when keyboard lock is active.
- String changes made/needed?: No
- Is Android affected?: no
|
|
Assignee | |
Comment 16•2 months ago
|
||
This gives content a chance to deal with the input before chrome and
potentially preventDefault() them.
Original Revision: https://phabricator.services.mozilla.com/D296377
|
|
||
Updated•2 months ago
|
|
||
Updated•2 months ago
|
|
|
||
Comment 17•2 months ago
|
||
| uplift | ||
Description
•