New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 119881 link

Starred by 114 users

Issue metadata

Status: Assigned
Merged: issue 680809
EstimatedDays: ----
NextAction: 2017-04-05
OS: All
Pri: 2
Type: Feature

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

API to request key events normally reserved for browser shortcuts

Project Member Reported by, Mar 24 2012

Issue description

This was branched from 84332 since we have a partial solution for the key event problem described there (for Chrome Apps only). This bug is to track the more specific case of receiving these key events for general web content (a.k.a. the "drive-by web")

See 84332 for details about this general problem.

Affects all platforms. Although Mac is slightly less impacted since the Chrome shortcut keys are Cmd-based rather than Ctrl-based (so there are fewer conflicts).

Labels: Feature-Chromoting Hotlist-ImportantForGames
Are you aware of two proposals in progress...

The Keybindings experimental API, checked into trunk (by me).
The BrowserKeys API, currently being worked on (I think, by someone else).

It looks like what you are talking about has some overlap with probably more the BrowserKeys API than the KeyBinding API. Is this partial fix you mentioned related to either of them, or is this a third independent implementation?

Comment 3 by, Apr 1 2012

garykac@ put forward the BrowserKeys API proposal. :)
Excellent. I asked because I hadn't seen the BrowserKeys implementation float by so I assumed this was something different (didn't remember who put up the BrowserKeys proposal).

Comment 5 by, Aug 2 2012

Labels: -Feature-Chromoting
Owner: ----
Status: Available
This bug no longer affects Chromoting, which is a Chrome packaged app.

Comment 6 by, Aug 30 2012

A bit of clarity would be great here.

Are either proposals actually moving forward? Could I stick with Chrome and still have a method of using Ctrl+W and Ctrl+T for a keyboard enabled page?

Comment 7 by, Aug 30 2012

Does this mean ctrl-w/n/t etc will be available for use in google chrome browser soon?  I certainly hope so.  I am tired of having to use firefox to get my work done.

Any update on this one?

Comment 9 by, Dec 18 2012

Blocking: chromium:151862

Comment 10 by, Dec 19 2012

Blocking: chromium:166895

Comment 11 by, Dec 19 2012

Blocking: -chromium:166895

Comment 12 by, Dec 19 2012

Blocking: -chromium:151862

Comment 13 Deleted

Project Member

Comment 14 by, Mar 10 2013

Labels: -Area-Internals Cr-Internals
@garykac, @finnur, checking in about a year later.  Any new motion occurring?

Comment 16 by, Jul 24 2013

I am guessing that the devs feel this only effects a handful of power users who don't matter when looking at the statistics.

Every single time I author something and need to bounce Chrome users to an "Install Firefox" page I do an internal face-palm. 
I am seriously disappointed that this has not made any progress.  Walking users through creating an application shortcut on the user's desktop is *not* a solution to the problem of basic keystrokes not working.

Also, requiring that the user install an "app" in Chrome is not a solution since that only works for permanent, dedicated SaaS offerings where the URL will never change.  When everyone runs their own instance of a web-based application (for security reasons) they will not want to have to register a developer account and install their application in the Chrome Web Store.  Not to mention the fact that this would make something public that should be private.  It also adds a lot of additional steps to something that should "just work": A  web-based application.

Here's the use case:  Embed a web-based terminal into things like appliances control panels, virtual machines, console servers, and whatnot.  Users will naturally try to use Ctrl-W to switch views in vim and will be surprised as fsck (and seriously angry) when their browser tab closes.

Note:  I am also working on a web-based X11 emulator that will run into this problem.  How can I expect it to be embedded into all these useful situations if there's no mechanism provided to override the default keyboard shortcuts?  Users running Chrome inside of Chrome will inadvertently close the parent browser tab when they really just wanted to close the one inside the web-based X11 session.

Chromoting had this problem but since that's an application that runs on the client itself they created a Chrome app and declared it, "problem solved."  That "solution" just does not work for most web-based applications.

Comment 18 by Deleted ...@, Sep 1 2013

Um Well I'm taking a highschool online class and for me to do that I need to be able to type some ltters in spanish but I can't becase different things keep happening

Comment 19 Deleted

Comment 20 by, Feb 26 2014

I work on a desktop remoting solution (VMware Horizon View - HTML Access), and having access to the entire keyboard would be perfect.

Comment 21 by, Feb 26 2014

Now that this issue is causing trouble for VMWare Horizon View (Google partner) perhaps we can get some action on this issue!  Escalate to your superiors now or your users will start to get really pissed not being able to Ctrl-T in their VMWare virtual desktops.
Hello, I have a web app and I am using Ctrl+N for New file anc Ctrl+T for Free transform. I prevent default behavior by Event.preventDefault(). It works in all browsers except Chrome (and Chromium). Why don't you fix it? 

You can keep Escape for escaping the fullscreen, but you should provide other keys to web developers.

Comment 23 by Deleted ...@, Dec 16 2014


Comment 24 by, Jul 13 2015

I would love an update on this.

Developing a game and attempting to model the same keys as the multi million user game League of Legends. As well as Dota and Heroes of the Storm, and yet I simply cannot do that because of this silly limitation that only exists in chrome.

Please add at least an api that allows me to override this functionality with user permission so the game could at least be played on chrome.
We can do this in IE and Firefox. Please let Chrome support it too.

Comment 26 by Deleted ...@, Jul 14 2015

Definitely would be nice to have this. Our web app would benefit greatly from this.
+1 from another web app developer.  Apart from anything else, it's a annoying that ctrl-o for open works, but ctrl-n does not.  It makes my app look shonky. 
Can we get a statement from the Chrome developers about this one way or the other?  This bug has been open for over three years and there's been no movement.  If you're not planning on providing support for overriding Ctrl-T, Ctrl-W, and Ctrl-N then just say so and close this issue.

Users using web-based terminals *really* need the ability to Ctrl-T and Ctrl-W!
Assigning to me.

The main considerations here are the security and UX implications. There are definitely risks of sites abusing this ability to prevent users from easily closing the tab, for example. There is also the UX question of whether users will be confused why certain browser shortcuts work differently on different sites (although that's obviously less of an issue in remote desktop scenarios).

I'll follow up with the UX and security teams to get their assessment so we can hopefully either start work on this or mark this as something we unfortunately won't be able to support.

Also note that searching online for keywords relating to this provides a reasonable split of feedback between users frustrated by sites intercepting their shortcuts, and developers requesting to be able to intercept them. And Mozilla's bug tracking this has 160 comments so far, demonstrating how contentious this issue is (
Labels: -Type-Bug -nomedia -Cr-Internals Type-Feature OS-All Cr-Blink-Input

Comment 31 by, Oct 9 2015

Ctrl-N and Ctrl-T do nothing in Panels - the small windows of the Panel type. In Chrome apps these keys also do nothing. Obviously you can allow overriding the unused keys at least. Or add a manifest.json permission.
Personally, my main gripe is with CTRL-W. I press that all the time, when editing text in a remote session. And it has pretty devastating consequences in a browser. I tend to lose all my state.

Comment 33 by, Oct 9 2015

Whether allowing tabs to capture fundamental keystrokes is useful isn't even up for debate. It's useful and absolutely needed. It's used quite regularly in Web apps on "those other browsers". It's used in packaged Chrome apps, which already have this capability, but not every Web app is a packaged app.

What isn't fully formed is how that capture capability is implemented: API, chrome:flags switch, an extension which triggers the API based on loaded URL, or some combination/mixture of these.
1. Normal users barely use shortcut keys, especially keys like Ctrl+W

2. Users frustrated by sites intercepting their shortcuts: if user is on a Remote Desktop session or SSH session, user will be frustrated sites can not intercepting shortcuts. If the site is not supposed to do so, user should blame the site developer, not browser. browser should not punish innocent developer because of this.

3. Chrome is the only browser which is blocking those shortcuts and you don't have a workaround for this.


Comment 35 by, Oct 12 2015

I think we all can agree that the ability to override keyboard shortcuts is an important and useful feature.  Yes, it does provide web pages with the ability to be seriously annoying but it's not a show-stopper.  If it were, users would be complaining a *lot* more and a lot louder about this.

Now consider how much of a show-stopper it is for web applications that *need* the power to override things like Ctrl-T and Ctrl-W.  Consider a web-based terminal emulator or a remote desktop application:  Without the ability to override keyboard shortcuts users would be in for one hell of a surprise when they Ctrl-W to switch viewports in vim only to find that their browser tab just closed; potentially losing all their work!  The same thing would happen to a user that tried to close a window inside of a virtual desktop only to find that their whole session just got disconnected due to the tab being closed.

So from a user perspective web pages that override these shortcuts *in a bad way* are merely annoying but the inability of web applications to override certain shortcuts is most certainly a *usability nightmare*.
Emacs mode

Comment 38 by Deleted ...@, Nov 3 2015

Yea I can't even code with Gateone ssh with vim because all of my vim keybindings don't work. This is seriously hindering chrome to be used for any serious web apps. It is a shame, I guess I am going to have to switch browsers.

Comment 39 by Deleted ...@, Nov 27 2015

Im writing a realtimestrategy game in html5 and it is indeed annoying that im not able to use keycombinations like ctrl+w  or ctrl+t

Comment 41 by, Jan 21 2016

This is a serious issue for data entry systems.  Supporting a large siebel enterprise and users use Ctrl-N to create new lines.  Chrome has been much more stable then other browsers but this is creating critical issues in UX and performance for the user base.
Any updates?  This is a blocking bug for my application.

Developing an emulator of various desktop applications. These applications use the shorcuts in question to perform various functions.  User needs to be able to press these without risk of closing tabs, browser, etc.  I cannot allow them to do that now because of this limitation that only exists in chrome.  Furthermore, I must alert users, most annoyingly, to specifically NOT press these keys in Chrome lest they mess up their test environment.
Status: Assigned (was: Available)
Guys, this has been carried on since more than 6 years now.
The solution that you offered is not enough, while it shows you listen to our complaints, this should not have been a problem in the first place.
As of today, May 23, 2016 - intercepting CTRL + T in various browsers:

document.addEventListener('keydown', function(e) { e.preventDefault(); e.stopPropagation(); console.log(e); return false; });

- Firefox 46.0.2 => intercepted properly
- Internet Explorer 11.306 => intercepted properly
- Microsoft Edge => intercepted properly
- Safari and Chrome => Not Possible at All(CMD + H is possible in Safari)

Maybe there is a lot of politics that revolves around solving these kind of issues, but they are so frustrating for developers.
Assigning to the engineers currently investigating this
There is a discussion of the problem and suggested proposal in this GitHub repo:

Proposal suggests restricting special key overrides to full screen only.
This is ok for games, but not for my terminal client where I want press
ctrl-w without being in full screen.
We're currently proposing a fullscreen restriction, but that may be lifted in the future. The main concern is that this API is quite powerful (hence we need to prevent bad actors from being able to lock people into a state where it's non-obvious how to get out). At the same time we don't want to have overly intrusive bubbles or messages interrupting users when they have a keyboard lock enabled.

Of course, feedback over time if/when this is implemented might show that the security concerns aren't that serious (e.g. the pointer lock API started out as fullscreen only, then gradually made its way to be accessible outside of fullscreen as well).
Perhaps prompt the user for access like you would for webcam access or geolocation?
BTW I only want to override browser shortcuts and not OS shortcuts as indicated by the proposal. So I wouldn't want to over-ride alt+tab or ctrl+alt+delete. Maybe reserve OS shortcuts for fullscreen only.
#49: We don't want to add a new prompt. We are moving away from prompts in favour of just letting the user get out of a bad situation (recently we changed the fullscreen prompt to a "Press Esc to exit" notification). Webcam and geolocation need a prompt because they can do permanent damage; fullscreen and keyboard lock can be cancelled by the user with no ongoing harm or information leakage.

Comment 51 by, Jun 29 2016

Let me just state that I agree:  The user should not be prompted to allow the use of preventDefault() on a handful of simple keystrokes.  It should "just work" for them.  In other words, if the user is in a non-fullscreen terminal emulator, remote desktop application, or similar and they type ctrl-w it should *not* close the browser tab and should merely *follow the spec* which was written specifically to handle this kind of situation.  Calling preventDefault() on ctrl-t/w/n is a very natural thing to do.

The best user experience is to simply allow preventDefault() to work for those keystrokes.  By *not* allowing preventDefault() to work Chrome is breaking the web, not following the spec, and causing seemingly endless frustration for end users and developers alike.

Comment 52 by, Aug 26 2016

So... It seems that packaged apps are going away for non-CrOS platforms per this week's announcement. This means that making a packaged app will no longer be sufficient to work with applications which need to capture these keystrokes.

Priority of this bug should be increased at this point.
I gave up and moved to Android.
What Google's done to Chrome Apps is shameful.
We are kind of stuck as we can't offer full user experience because of this limitation.
Here's the case:
Ctrl+Shift+N shortcut is industry standard for Normal Style in text editing apps. We can't offer desktop and industry standard key short cuts. Apps should have the right to override these keys (only when they want, only when using these apps), so that the 99% of users of text editing apps can use their key short cuts. That was a wrong decision to assume the 1% of general users who use or even know browser short cuts should prevent the 99% of our customers using what they are used to.

Is there any idea for solving this problem?
Sending this over to Gary as he proposed System Keyboard Lock API to address this so he is actively working in this space.
NextAction: 2017-04-05
garykac@, what's the status/plan here? Predictability program has set an OKR to gain traction on the top 50 starred bugs this quarter: either by closing them, stating what milestone the fix will ship, or setting a NextAction date so that we know when to check back in.
Last week I sent out an "Intent to Implement and Ship" for "Browser Shortcuts in Fullscreen" to chromium-dev and blink-dev. It's currently under discussion. Our plan is to work on it this quarter (in conjunction with System Keyboard Lock since they're related).!topic/chromium-dev/q0ICx0y5540!topic/blink-dev/wlRDnLbyVlk

Note that we'd like to remove the fullscreen requirement eventually, but it's in place initially to address concerns about people using the API maliciously.

Mergedinto: 680809
Status: Duplicate (was: Assigned)
Merge into 680809 to track both System keyboard lock and Browser keyboard lock features.
FYI, this feature has been implemented by change
Blockedon: -680809
Status: Duplicate (was: Assigned)
I am unduplicating this bug because it has much more history and discussion than  issue 680809  (I'm blocking this on it instead). Plus,  issue 680809 's proposed changes are for fullscreen only.
Status: Assigned (was: Duplicate)

Comment 64 by, Feb 13 2017

Thanks. This bug is definitely targeting non-fullscreen (think in-browser IDEs / terminals, HTML5-Canvas based remote desktop clients, and so forth). Those applications don't need a global keyboard lock, only for all key events to be directed to the application when its tab has focus.

This has renewed urgency now that non-CrOS devices will lose the ability to run packaged apps soon. That's how vendors have worked around this problem up to this point: packaged apps automatically receive all key events, including ESC and F11.

What we probably need here (and would be the least intrusive to the applications themselves) is a requestable permission to do the same for any page, even in a generic tab, which can be saved in the same way as the permissions for desktop notifications, camera, microphone, etc.
#64: I've mentioned this elsewhere, but a permission has significant problems, not least of which is how to phrase the permission request in a way that makes sense and doesn't confuse the majority of users. There are also problems with the fact that listening for shortcuts is a synchronous action that can be run any time (attaching an event listener), while requesting a permission is asynchronous, with the prompt itself usually being indefinitely ignored or dismissed by users.

We are still trying to work out the best compromise here, but the fact that this issue is 5 years old really illustrates how tricky this is. :)

Comment 66 by, Feb 14 2017

It's unlikely that "trickiness" is the cause because the majority of users don't even know about nor use the keyboard shortcuts including the protected Ctrl- and Ctrl-Shift- N/T/W and Chrome aims to be the most accessible/popular browser, not geek-oriented.

Comment 67 by, Feb 14 2017

If the issue is complex enough that thinking about it for 5 years doesn't help, thinking about it more won't help either, the task needs to be split into smaller, more  manageable parts :)

First step would be to add the absolute minimum needed for sites using this to work.
That is only an entry in site settings saying:

[] Keyboard full control [block (default)]

Without any js api, and without a prompt to enable.

That will not be any more confusing than `MIDI devices full control`, and won't require any complex changes to the way shortcuts are handled now: ctrl-n will intercept the shortcut like it does now, check the site permission, and if keyboard access is allowed, leave the event for content process, and then handle bubbled up event the same way other keys are handled. 

If it's implemented in a similar way to "non-secure scripts". Then as soon as a reserved keybinding is blocked then it will show an icon in the address bar. Once approved the page will reload and allow any previously reserved keybindings to be set.

This is the least likely to affect the majority of users as it doesn't involve a direct prompt. And dev users will know to look out for it.

Comment 69 by, Feb 14 2017

See? It's not all that tricky. It's odd that we've been "thinking" about this for so long, when Chrome and CrOS's big selling point has always been "do anything via the Web".

For applications which need it, those sites can even show a little help blurb saying "click this and that to pass through all keystrokes". It doesn't necessarily have to be a prompt; it could simply be blocked by default.

If using a bar icon, the tip phrasing could be something along the lines of:

"This webpage wants full control of your keyboard, which prevents the use of browser shortcuts like Ctrl-W when this page is active. If enabled, you will need to use the tab strip and tab close buttons instead of keyboard shortcuts."
gary/zijieh@, we had a NextAction date in April (we had an intent to ship out and were hoping to make progress on this in Q1), so checking in to see how things are going, and what's left?

Comment 71 Deleted

Sorry for the misleading information in #c71.
We do not have a short term plan to support this feature in tab mode, but in exclusive fullscreen mode -- both Javascript fullscreen and user initiated F11 fullscreen with tab strip hidden -- this feature has been finished in M60. M59 contains required changes for both Windows and Linux, but not Mac OS.
Regarding to the detail of this feature, we do not have a new API, but only preventDefault().
You may find the example in the file (a.html) attached.
375 bytes View Download

Comment 74 by, May 25 2017

As long as the Apps platform is not removed from non-CrOS before this feature is fully implemented, we should be OK. The target is to make it possible for a tab to behave the way window-based packaged apps do today (as that's the only non-fullscreen way to catch these shortcuts today).

Comment 75 by, Oct 30 2017


We have been developing a management application that is now multi-browser compatible for several years (Internet Explorer, Edge, Firefox and Chrome). Keyboard shortcuts are widely used and especially the Ctrl + N because very friendly for users. In the business world, switching to full-screen mode or using Chrome in "application" mode is not conceivable in terms of use or deployment in administrations and other service centers.

Recently, we have seen the removal of the "showModalDialog" method, which is widely used in very high-performance management applications, even though it seems that your meters indicated a very low utilization rate at the public level. But in the business world?

The possibility of catching these keyboard shortcuts like the others and being able to make a "preventDefault" is the only good solution.

At this level, we have no problem with Internet Explorer / Edge which even if they have a delay with respect to Chrome on some features, they take more into consideration the world of business and the needs of management applications.


would this resolve issue 482926? (Extensions are unable to bind the Tab key)
This is a web platform API, so I don't think it will help for extensions.
Owner: ----
Status: Available (was: Assigned)
Status: Assigned (was: Available)

Sign in to add a comment