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

Issue metadata

Status: Fixed
Closed: Oct 2009
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Figure out how to deal with sluggish renderers blocking accelerators

Project Member Reported by, Dec 13 2008 Back to list

Issue description

Keyboard messages are sent to the current renderer for processing. This 
allows the web page to override most keystrokes. If they are unhandled, 
they are echoed back to the browser process.

This is good because web pages want to see the keystrokes. They can also 
override interesting commands such as Ctrl-P for print (they may want to 
provide their own print preview).

However, tab and window management commands aren't well suited for this. 
Even if the web page doesn't override the commands (which is very rare and 
possibly harmful or annoying to the user), the responsiveness of the 
browser to these messages depends on the responsiveness of the current 

For example, if the current renderer is hung, Ctrl-W won't close the tab. 
You have to use the mouse. If you have a slow or hung renderer and you use 
Ctrl-PageDown to cycle through the tabs, it will stop on the hung one and 
not continue.

I propose the following "non-maskable" commands which would be handled in 
the browser and never sent to the web page for processing.

Alt-F4 (this one probably already is)
Shift-Esc (task manager)

Comment 1 by, Dec 18 2008

Related issue:  5659 

Comment 3 by, May 14 2009

 Issue 5659  has been merged into this issue.

Comment 4 by, May 14 2009

Labels: Jank

Comment 5 by, May 14 2009

What about Esc button to stop load--shouldn't it join the list?

And I believe Alt-D for focusing at address bar definitely should be added to the list. 

Comment 6 by, May 14 2009

I think the line should be drawn at window management commands. There is no point in 
focusing the address bar or stopping the load if the page is hung.

Comment 7 by, May 14 2009

> There is no point in focusing the address bar or stopping the load if the page is 

When the page is still loading (which frequently takes dozens of seconds when Chrome 
has many open tabs, or when multiple tabs are loaded at the same time on a slow 
connection), both stop-loading and focus-address-bar-I'll-try-another-address are quite 
frequent scenarios.

Comment 8 by, May 14 2009

Stop especially doesn't matter. The page won't stop loading until the renderer 
responds, so it doesn't matter if the keystroke is also waiting for the renderer to 

Comment 9 by, Sep 11 2009

See  issue 5496 . We either need to do one or the other.

Comment 10 by, Sep 11 2009

Related issue with a bit more detail:  issue 21588 , which discusses the numeric tab-
switch keys, (ctl + number), how those have the potential to conflict with content, 
and how to address that.

Comment 11 by, Sep 11 2009

I like your list.  Ctrl+W and Alt+F4 however need to go through the renderer.  
Otherwise, beforeunload and unload handlers will be busted.  People could lose data.

Comment 12 by, Sep 11 2009

what about alt+d?

Comment 13 by, Sep 11 2009

Shall we start with a very small set?

I propose:
Shift-Esc (task manager)
Ctrl-Tab (switch tabs ->)
Ctrl-Shift-Tab (switch tabs <-)

Comment 14 by, Sep 11 2009

I just realized that my comment #11 doesn't make any sense.  The suggested change of 
having Ctrl+W, Ctrl+F4, and Alt+F4 always mean to close the current tab (or window) is 
fine.  The page will still be asked to run beforeunload / unload handlers just as if 
you had manually clicked the close box on the tab strip / window frame.
What if we only set keyboard focus on the renderer once it has responded to a set focus message?

In other words, when you switch to a tab we would wait to hear back that it is loaded before sending any 
keystrokes to it.
Therefore If an accelerator is entered before the renderer has responded, it will be handled immediately by 
the browser without any delay.

This would address the use-case where you are  quickly ctrl-tabbing between tabs, without having to 
hardcode any accelerators and possibly break web compatibility.

Comment 16 by, Sep 16 2009

 Issue 9640  has been merged into this issue.
Summary: Figure out how to deal with sluggish renderers blocking accelerators (was: NULL)
Broadening to cover any possible solution to this problem.  Jank triage team is 
skeptical that any set of accelerators should be "reserved" -- for example, consider 
an MDI or tabbed document editor in the browser, where ctrl-tab or ctrl-w or 
something might conceivably make sense.  However, it's possible we're wrong.

Evan's idea is to timeout on these.  This has its own problems, like inconsistent/flaky 

It's possible there is no good solution here.  Or perhaps we can do more to make 
long activities in the renderer more re-entrant so that at least _more_ frequently we 
can respond to browser requests.

The goal here is for someone to determine:
* What the cases in which this happens are (e.g. hung renderer is distinct from 
"layout takes a long time")
* For each case, whether there is any good solution

Leaving open for a Jank team member to take.
 Issue 21588  has been merged into this issue.

Comment 19 Deleted

In case it helps, here is the list of accelerators on Windows that I'm aware of to 
open/close/switch tabs/windows:

New tab: ctrl-t
New window: ctrl-n, ctrl-shift-n
Close tab: ctrl-f4, ctrl-w
Close window: ctrl-shift-w, alt-f4
Reopen closed tab/window: ctrl-shift-t
Change tab: ctrl-# (# = 1, 2, ...), ctrl-tab, ctrl-pgdn, ctrl-shift-tab, ctrl-pgup
Change window: alt-tab

I don't believe alt-xxx are overridable by script, but the rest are.

I am confused about Darin's comment 11.  Unless pages are trying to listen directly 
for ctrl-w (or similar) and act on it, instead of putting handlers in 
on[before]unload, they wouldn't be hurt by not roundtripping these.

In hand-waving theory land, I kind of wish a few things were true:
* The browser could know "ahead of time" which accelerators a page did/didn't care 
about, so it could avoid roundtripping accelerators in the latter category at any 
* Overriding "important" accelerators was, if not impossible, more difficult or 
demanding for pages, or made it clearer to authors the consequences of doing such a 
thing (in the sense of trying to make it harder to "accidentally" misuse something)

If we do elect not to round-trip certain accelerators, I think we should try to get 
Mozilla, Apple and Opera on board if we can, so web authors will have some kind of 
consistent behavior they can expect.

Note that in the past Mozilla has tried to make various changes to reserve different 
accelerator patterns for content versus chrome (e.g. "ctrl-xxx" vs. "ctrl-shift-
xxx").  Not sure what the current state of that is.
Followup note: Firefox reserves ctrl-shift-n for "reopen closed window"; they use 
ctrl-shift-p for their equivalent to our ctrl-shift-n.  Safari doesn't use ctrl-
shift-t for "reopen closed tab" at all; there it toggles the tab strip.  I'm not sure 
Opera has either of these.  IE definitely doesn't, and IE and Safari probably also 
lack support for a bunch of the other accelerators.

Cross-browser consistency and cross-platform consistency are problems (though not 
absolute deal-killers) for not round-tripping certain accelerators, since web authors 
can't rely on something being available or not.

I know people hate slippery slope arguments, but given that tabs, reopening closed 
windows and private browsing modes are all inventions of the last several years, I 
wonder how many things we'll invent in the future that we want reserved too.  And as 
web apps get more and more powerful, and (in Chrome OS) are the entirety of the user 
experience, how much more likely is it that my worries in comment 17, where "tab 
manipulation commands" start being meaningful inside a web app, come true?

All I am really asking is that this be given grave consideration and the future 
consequences pondered carefully before taking action.
For the record, I still support doing this. I'm not worried about the slippery slope 
arguments at all, we just need 

I think having more of the entirety of your experience in the browser means the exact 
opposite of what Peter deduced. If my windowing primitive is the tab, I REALLY don't 
want a web page to interfere with it, just like no browser allows web pages to hook 
alt-tab and (I think) alt-f4.

Comment 23 by, Sep 21 2009

Another idea here is to still send these special accelerator into the renderer, but 
simply not let the renderer swallow them.

That probably has less of a compat impact.
To put it more simply, I don't think we should worry about future hypothetical web 
applications that feel the need to trap Control-PageUp and do something other than 
switch tabs (which I still don't understand why I would want under any circumstances), 
and instead worry about the things that affects every single web page today (like that 
switching tabs is slow using the keyboard).

Comment 25 by, Sep 22 2009

I just tested Evan's test case at http://~evanm/projects/chrome/keyboard.html which 
swallows all events in Firefox, Safari, Opera and IE.  All of them allow navigation 
back and forth between tabs, closing tabs, creating new windows and creating new tabs 
using keyboard shortcuts.  Chrome is the only one that fails.

I think we should make all of our keyboard accelerators not go through the renderer.  
The full list is available at
Status: Assigned (was: NULL)
@25: that sounds a bit drastic. It appears to me that firefox short-circuits ctrl+tab 
and ctrl+pagedown (and possibly others) but not ctrl+t or ctrl+n or ctrl+f, etc. There 
are a *lot* of browser accelerators so we can't make a blanket rule like that 
(canonical example: ctrl+b bolds text in certain online WYSIWYG text editors, but we 
map it to toggle bookmark bar).

Comment 27 by, Sep 22 2009

Estade: I tested on Windows, and ctrl+t, ctrl+n and ctrl+f all work in Firefox.  
Perhaps you're testing on Linux and the behavior there is different.

I agree ctrl+b shouldn't be done.  Based on comments above, this is what I agree we 
should do:


Comment 28 by, Sep 22 2009

evanm's test page doesn't eat all the appropriate events.  This page can be set to eat 
ctrl+t/ctrl+n, etc:

Trying to leave evanm's page in Firefox windows causes all sorts of jank as well 
(e.g., the tab will disappear, but will hang the browser).  In Firefox, the script 
timeout is what saves you (you have to stop the script to get away).

Comment 29 by, Sep 22 2009

Also Alt+F4, which works correctly on 4.0 but not trunk.
no, I was testing on Windows, but I was using the link Tony provided rather than 
Evan's test page.

I think ctrl+tab/ctrl-shift-tab should be added to the list. 

Comment 31 by, Sep 22 2009

I updated the test to return false, so that Firefox eats ctrl+t/ctrl+n.  I removed the 
onunload stuff since it's a different issue and is fixed in Chrome now.

All the other browsers allow ctrl+tab, ctrl+shift+tab, ctrl+f4.  All except Firefox allow 
alt+f4.  Opera/IE allow ctrl+w.  Of the browsers that support ctrl+# (IE, FF, Safari, 
Chrome), IE allows ctrl+# to work.

Any objections to doing the list in comment 27 + 29?

Comment 32 by, Sep 22 2009

oops, yes of course ctrl+tab and ctrl+shift+tab as well.
It seems that firefox actually does what aa@ mentioned in comment 23 (sends the event 
to the renderer but doesn't let it swallow it). Thus if you did have a webapp that 
listened for ctrl+pgdn you could stick it in its own window and still use it to its 
full potential.

Comment 34 by, Sep 23 2009

Sending to the renderer seems like it could be a bit problematic: i.e. you can't just 
send it and not allow it to swallow it, since if we did that a hung renderer would 
still block the key from being processed by the browser.  So we'd have to do it in 
parallel, which means if it's a tab close/switch using the variety of the methods, the 
user wouldn't see the result of it anyways which seems to defeat the point of sending 
it to the page.

I'm inclined to just not send these particular key combinations to the renderer.
@34: the user would see the result if chrome were in app mode, where ctrl+pgdn does 
nothing in the ui.

Comment 36 by, Sep 23 2009

Given that the majority of the usage isn't in app mode, I think we should optimize for 
it since it would be strange to have different behavior in both modes (or for different 
key combinations).

Comment 37 by, Sep 23 2009

Sounds fine to me, at least as a starting point. We can refine later as needed.
@36: I strongly disagree that app mode is not worth optimizing for. In app mode, 
there is supposed to be essentially ZERO chrome, so why reserve ctrl+pgdn if it does 

Firefox sends more key press events to the page on ctrl+pgdn when you are in a 
browser window that only has one tab. If we send the key to the page as well as 
handling it in the browser, then we leave the door open for a user workaround for 
pages such as google spreadsheet. If not, then there is no possible workaround, 
except to launch firefox.

As far as not having different behavior for different key combinations, this solution 
breaks that expectation either way.

Comment 39 by, Sep 23 2009

The point I was making is that it will be very confusing if some key combinations like ctrl+pgdn are sent to the tab in app 
mode but not in normal Chrome.  We need to have these two modes be identical from the web developer viewpoint since having 
compat issues between different modes of the same browser sucks.

So the question is, do we send it to the page or not?  I state that sending an event to the page after it's been switched 
from or closed is next to useless.  If you can find a page where ctrl+pgdn is needed, that would be an interesting data 
point.  But until then, I'd like to have consistency in how keyboard accelerators are handled by Chrome and exposed to 
re 39: Google Spreadsheet binds ctrl+pgdn/pgup

Comment 41 by, Sep 23 2009

Interesting.  However it doesn't work in Chrome, Safari or Firefox.

I don't feel that strongly about whether we should reserve it though.  Looks like ctrl+1..9 are 
used by Docs as well.

So perhaps we should narrow it down slightly to this list.


Comment 42 by, Sep 30 2009

The following revision refers to this bug: 

r27814 | | 2009-10-01 18:25:41 -0700 (Thu, 01 Oct 2009) | 5 lines
Changed paths:

Don't send tab switching/killing/creating keyboard accelerators to pages.  This avoids tabs maliciously preventing closing using ctrl+f4/ctrl+w/alt+f4, and also hung/slow renderers from making tab cycling sluggish.

BUG= 5496 
TEST=added ui test
Review URL:

The following revision refers to this bug: 

r27823 | | 2009-10-01 20:30:49 -0700 (Thu, 01 Oct 2009) | 5 lines
Changed paths:

For some reason, if the interactive test that I added runs after inprocess tests (still in interactive tests), it gives an assert in Linux before it starts because the existing process count is 2.  Moving it to a different file solves the prolbem.

BUG= 5496 
Review URL:

Comment 45 by, Oct 2 2009

Status: Fixed (was: NULL)
Just tested the CL and as I said, it can't handle keyboard layout correctly on Linux. 
How to reproduce:
1. Switch keyboard layout to Russian or other similar layouts.
2. Open
3. Uncheck all suppress check boxes and try if keys like ctrl-t, ctrl-w work.
4. Check suppress keydown check box and try these keys again. You may find these keys 
stop working. They will still work if the keyboard layout is US.

Comment 47 by, Oct 9 2009

I must not have tested with a page that has page down then.  I've filed  bug 24479  to 
track this issue.
The following revision refers to this bug: 

r30032 | | 2009-10-25 21:40:12 -0700 (Sun, 25 Oct 2009) | 12 lines
Changed paths:

Do not send some keyboard shortcuts to the renderers

Walking the whole menu on every keypress seems ridiculous. Linux does this too :-/ (Caching is made hard because the user can change key equivalents in system preferences at every point in time, and we're not notified of that. And people only hit max 5 keys/second, so it's not all that ridiculous).

There's a UI test for this, but the interactive UI tests are not enabled on OS X, so it's not executed.

Menu walking code based on code from CocoatechCore.

BUG= 5496 , 15090 , 24877 
TEST=Go to , check "keydown", focus the textbox, and make sure that cmd-t still opens tabs, cmd-shift-[ still switches tabs, cmd-w still closes tabs. however, cmd-L should not focus url bar and cmd-1 should not go to the first tab.

Review URL:

Sorry to beat this dead horse, but:

Both Linux and Mac have a shortcut for "Quit app" which closes all open windows (cmd-
shift-q on linux, cmd-q on mac). Windows doesn't seem to have a shortcut for that. 
Should the "quit app" shortcut be included in the shortcutted list as well?

Comment 50 by, Oct 27 2009

Thakis: that sounds reasonable to me.  The question I ask is, would you want a page to 
block this?
Ok, I filed  issue 26054  to track handling of cmd-shift-q/cmd-q.

Comment 52 by, Nov 10 2009

I don't know if this is related (I am sorry but some of terms you use are not in my 
technical vocabulary)...Every so often a page I am on redirects me to some malware 
site that tries to download a virus scanning software into my computer. It hasnt 
happened in a while, so perhaps this has been fixed (?), but the problem I was facing 
would prevent the tab from closing either by shortcut or manual closing. I was even 
unable to close the entire Chrome session. Meanwhile, the scanning/installation would 
continue undeterred. 

ANYWAY, I made a bug report about this:  issue 21575 . 

When I first started looking over the code chromium page, I submitted this, and was 
asked if it was related to a revision which was linked to this bug...

I am making this entry to see if this is a related bug, and asking if it would be 
appropriate to merge my report (21575) into this?

But only if they deal with the same thing: bottom line, malicious site prevents 
closing of tab/chrome session

(I was only able to fix this with ctrl/alt/delete, and in one instance, a forced 
crash of my HDD)

Comment 53 by, Jan 27 2010

Is there a way to make this an option for users?  Perhaps allow user specified domains 
to override these keys?  Right now I have to switch to firefox to use websites that 
rely on capturing and using these keystrokes.  I'd much rather use chrome.
superjoe: Can you provide a list of the websites you're talking about and the keys they 
override that don't work in chrome?

Comment 55 by, Jan 28 2010

In Cappuccino apps we catch command+w and close internal (inside the browser) windows first, and finally allow 
it to bubble up to the actual native windows once those have all been closed. The idea is that with web apps that 
have inner windows, we don't want the user accidentally closing the main window when the meant to close the 
inner window. The effect is quite nice because you can still close the main window by hitting command+w again.

Comment 56 by, Mar 3 2010

This really is a slippery slope.

Too many combinations reserved by the browser and it loses flexibility as an app platform. 

It has been suggested that differing sets of reserved keys for Chrome in browser vs app mode is 
bad for compatibility, but I don't see why. App developers already can't rely on Ctrl-PgDn being 
available, so making it available in app mode does not present any new challenge to them. 

These keys should be passed to any app for processing:


In fact Ctrl-T and Ctrl-N _especially_ should be passed in for blocking, since _apps_ don't 
necessarily want to allow users to spawn _browser_ windows. 

I want to see Chrome be the first browser to truly embrace the browser-as-OS-webpage-as-
application paradigm, and loosening the reserved key rules in app mode will be a fantastic step 
towards this. 

Comment 57 by, Oct 19 2010

i need Ctrl-N excluded from chrome's reserved key accelerator list.

1. all other major browsers do( IE6, Firefox );
2. less important for tab-browser era;
3. Windows, Mac, and GNU/Linux all recommend it for "Open new document" #1;
4. brettw's concern is less applicable to it;
5. fix Google's shortcut(the only exception) from Ctrl+M to Ctrl+N for "new slide" #2.

Win: UXGuide.pdf P419 (

Keyboard shortcuts for Google presentations(Comment #40):

Comment 58 Deleted

Comment 58 by akarchen, Today (moments ago)
hi, me again.

Not one pay attention this issue anymore?

finally, i found a solution for this:

I can custom those Ctrl-keys i need, and deploy to all the intranet clients.

Web App developer
I've started a thread on chromium-discuss to talk about this issue.

Masking Ctrl-W kills software development with emacs-like editors on the web.  This is going to have to change eventually if people are going to have fully functional web applications without land-mines that close the whole browser when you try to cut some text.  Why not have the default be masked, and users that don't like it can unmask selected ones.  These can be synced to provide a consistent user experience.  If you don't want to add new settings, then maybe add an API hook to the extension interface that lets you change the masked keys programmatically.

Comment 62 by, Mar 4 2011

The problem is not just a particular shortcut. Any complex Web2+ application requires (could use) ALL of the above shortcuts to enhance productivity and lower the learning curve. F.e. Ctrl-(Shift)-N/W is the way the users are aware of to create/close items, pages, records, you name it. Ctrl-PageUp and PageDn are useful to cycle collections, regardless of their type. The whole world is moving their legacy applications to take advantage of the web delivery infrastructure - especially visible in the intranet space, this is quickly becoming apparent in the wide web too. The pages that you're trying to protect are destined to the fate of the gopher sooner, rather than later! Don't be over-protective, restrict the bare minimum or learn the lesson the hard way.

Comment 63 by, Mar 4 2011

What he said!
Please discuss on the thread.

I'd like to get a consensus on the best way forward there.

It seems that just rolling this back will not be possible, so we need
as much ammunition for the best way forward as we can get.

After we get one, I'll file a bug to implement the change we come up with.

Comment 65 by, Mar 11 2011

first, second or third-class?

Old days, we developed apps for DOS, we had all key buttons, that was first-class. When the day GUI OS came, those DOS apps were running in VM, became second-class. New OS key button were introduced physically to keybaord, finally DOS apps still can have all the key buttons they once had, positioning in second, but still feeling as first-class.

Will a promosing web browser position web apps running in it as third-class citizen?

(Please reserved none, novices are happy to close a tab by one mouse click.)


Comment 66 Deleted

Comment 67 by, Mar 26 2011

laforge, This is a copy of the first message in this bug, and it raises valid points.

It's a bit of a punt to say that this problem is too hard to solve, so we're going to put in a hack which diminishes the browsers use as an apps platform.

I still have not gotten a good answer on why we can't do one of the following:

1) Revert the change in 5496, and improve the renders so that they do 
not block. This feels like the most elegant solution. 
2) Analise the JavaScript on a given page and only send Ctrl-W to the 
render if needed. 
3) (variant on 2) Add a JavaScript function call which allows the 
program to request access to keys like Ctrl-W, etc. (If 2 is not 
4) We can further extend the concept in 3 by showing an allow or deny 
access dialog à la the geo location dialog. 
5) We can make the preference for these keys a configuration option. 


Comment 68 by, Mar 27 2011

This also kills important apps, and app possibilities, for CrOS and NaCl. Several of these keystrokes are very important in those environments.

For instance, ThinVNC is a canvas-based remote access application that gives a taste of what Chromoting might be like to non-devs. Ctrl-[NTW] are used by plenty of applications that would be accessed in a remote manner.

For M12 (or M13 at the latest), this should simply be _reverted_. If there's a desire to provide "less jank" for tab manipulation operations, then perhaps this is looking for a better solution, e.g.:

1. communicates the fact that keystrokes are being caught, using existing APIs, from renderer to main process;

2. provides a new API that can produce the information in (1) in a more granular fashion, to allow apps a way to enumerate the desired keydown events up front.

Comment 69 by, Sep 20 2011

I've been developing a web-based terminal emulator and the fact that preventDefault() does not work with Ctrl-[NTW] is a severe hindrance on its capabilities.  The author of comment 66 states that a web page overriding these keystrokes could be harmful or annoying but how harmful and annoying would it be for a user working in a terminal application to suddenly have their application close when they hit Ctrl-W?!?  That seems much more harmful and annoying to me.

Can we please revert this change?  If necessary I wouldn't mind invoking some window.webkit* function ask the user for permission to override these keystrokes in the same way they can get asked for permission for an app to use desktop notifications.

Comment 70 by, Sep 20 2011

 Issue 84332  tracks design of an API to provide access to reserved key sequences.  Please star that issue rather than adding further comments here - thanks!
Project Member

Comment 71 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Note to self: The code that implements this was refactored here:

(now done in PreHandleKeyboardEvent and IsReservedCommandOrKey)

Sign in to add a comment