Contact emails
Eng: gar...@chromium.org, zij...@chromium.org, jamie...@chromium.org, domi...@chromium.org, mgi...@chromium.org
Spec
No spec changes.
Fullscreen API spec (see relevant discussion in issue #39)
Summary
Chrome currently has a number of "browser" shortcut keys that are not sent to the web app. For example, the following (related to managing tabs and windows):
Ctrl/Cmd + (T | W | N)
Ctrl/Cmd + Shift + (T | W | N)
We propose that all keys normally reserved by the browser (except Escape and/or F11, as appropriate) should be sent to the app when the browser is in fullscreen mode.
In addition, the mouse forward and back buttons (which are used to navigate forward/backward in tab history), should also be sent to the web app when in fullscreen. This is to make the behavior consistent with keyboard forward/back buttons (found on some multimedia keyboards).
Motivation
Some web apps, like remote access apps and games, need access to keys that are taken by the Chrome UI:
Ctrl-T, W and N are all common emacs (text editor) commands.
In a remote access scenario, the user may wish to use these shortcuts with the remote app.
In games, W is a common movement key and modifiers (like Shift or Control) can be used to modify the movement in that direction.
Currently, Chrome apps can address this problem by setting "open as window" which gives access to these browser shortcuts. However, the recent deprecation announcement means that we need another mechanism for making these shortcuts available.
Developer interest: Developers often request the ability to capture browser shortcuts universally. However, permitting this means that sites could disable important user functionality. Our fullscreen-only proposal is a compromise: in fullscreen, it is clearly signalled that pressing Esc will exit, and the fullscreened site is clearly the entire focus of the user's attention..
Related bugs: 25756, 33056, 614145, 638585, 648469, 677680
Note 1: These keys are currently filtered from apps in Chrome for UX/perf reasons. For example, pressing Ctrl-T multiple times to switch tabs can be unbearably slow if each tab needs to be loaded to see if it wants to override the key combo. See 5496. Firefox made their recent behavior change (see below) for similar reasons.
Note 2: How this Intent is related to the recent Intent to Implement for "System Keyboard Lock". The System Keyboard Lock proposal focuses on keys (and shortcuts) that the browser does not normally handle (like Alt-Tab), whereas this proposal focuses on shortcuts that the browser does normally handle (like Ctrl-T).
With this Intent, we are proposing:
Which keys are sent to web app? | In Fullscreen | Not in Fullscreen | |
By default | Via SysKeyLock | ||
System Keys (e.g., Alt-Tab) | no | yes | no |
Browser Keys (e.g., Ctrl-T) | yes | Not needed | no |
Esc | no | yes | yes |
If we do not go ahead with this Intent, then the System Keyboard Lock API would be needed for Browser keys as well, and sites that required browser keys would need to make use of the System Keyboard Lock API.
Interoperability and Compatibility Risk
Medium, although note that we're not trying to get agreement with this Intent since this is a browser UX issue.
Edge: All these keys can be captured in or out of fullscreen
Firefox: Previously, these keys were sent, but in recent builds they are no longer sent due to lock-up issues in the multiprocess architecture. See 1074971 for change. Also see 380637 for discussion, but skip down to comment #185 if you value your sanity.
Safari: Blocks an even larger set of Cmd-* key combinations from being sent.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Windows, Mac, Linux and ChromeOS.
As currently defined, this feature is not applicable on mobile platforms.
Tracking bug
https://crbug.com/680737 (for browser keys in fullscreen)
https://crbug.com/680741 (for mouse forward/backward in fullscreen)
Requesting approval to ship?
Yes.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Windows, Mac, Linux and ChromeOS.
As currently defined, this feature is not applicable on mobile platforms.
On Tue, Jan 17, 2017 at 4:31 PM, Gary Kacmarcik (Кошмарчик) <gar...@chromium.org> wrote:Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Windows, Mac, Linux and ChromeOS.
As currently defined, this feature is not applicable on mobile platforms.
It seems applicable to Android. Chrome for Android supports Fullscreen API, and it's possible to connect a physical keyboard via Bluetooth, USB host or proprietary attachment (e.g. Pixel C), and a subset of shortcuts like Ctrl-T is indeed handled. Could you add that platform to the plan?
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
LGTM3. I just tested Firefox and Ctrl-T in fullscreen exits fullscreen and opens a new tab, which is also what Chrome does. Making it possible to use those for in-app things makes sense from an API perspective. However, if any security folks have input on this, that would be interesting.
Thanks for the thoughtful response Rick. I understand your motivation for the change and was mostly just curious to know how many people might be impacted by it.
In my opinion I don't know that there is necessarily a right answer to what should happen with accelerators when fullscreen. For power users familiar with the app then giving the page first crack is definitely expected. On the other hand casual users are more likely to be familiar with and expect accelerators to be processed by chrome first. This is why I suggested offering users the ability to opt-in to this functionality. Again, this is my just opinion, it would be good to involve UX in this decision.
On Thu, Jan 26, 2017 at 1:19 PM, Scott Violet <s...@chromium.org> wrote:In my opinion I don't know that there is necessarily a right answer to what should happen with accelerators when fullscreen. For power users familiar with the app then giving the page first crack is definitely expected. On the other hand casual users are more likely to be familiar with and expect accelerators to be processed by chrome first. This is why I suggested offering users the ability to opt-in to this functionality. Again, this is my just opinion, it would be good to involve UX in this decision.
Yeah whenever there are substantial UX concerns, features should generally go through the internal go/newChromeFeature process (in addition to this web platform process here). Gary et. al., let us know if there's anything you need from me or other web-platform folks there.