Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 117 users
Status: WontFix
Owner: ----
Closed: Feb 2010
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment
Ctrl keys: Ctrl-N, Ctrl-T and Ctrl-W no longer available to client side JavaScript in Chrome4 (available in FF3.x, IE7/8 and Chrome3).
Reported by, Jan 25 2010 Back to list
Chrome Version       :
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: Not tested
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1.  Load the attached simple web page in each browser.
2.  Position the cursor in the input field and press Ctrl-N
3.  If using Chrome, open the web page afresh and press Ctrl-T
4.  If using Chrome, open the web page afresh and press Ctrl-W
5.  As above but using Ctrl-Shift-N, Ctrl-Shift-T and  Ctrl-Shift-W.

What is the expected result?
The text "Ctrl-N", "Ctrl-T" or "Ctrl-W" (as appropriate) should appear in 
the blue div and the default action of the Control key should be prevented.  
(Similarly with Ctrl-Shift-N, Ctrl-Shift-T and Ctrl-Shift-W.)

What happens instead?
In Chrome4 the browser executes the default action (i.e. open new window, 
open new tab and close tab/window) and does not execute the JavaScript 
intercept (at all).
In IE7, IE8, FF3, FF3.5 and Chrome3 the intercept works fine.

Please provide any additional information below. Attach a screenshot if

In Chrome4, certain control key combinations have been reserved for browser 
usage only and can no longer be intercepted by the client side JavaScript 
in the web page.
These restrictions did not exist in Chrome3 and are inconsistent with both 
Firefox3/3.5 and IE7/8 (on Windows).
They are unnecessary in my view, and have prevented me from implementing 
certain user friendly keyboard interactions consistently across the major 
I am developing a brand new browser based business application and had 
already implemented Ctrl-N as a familiar shortcut for "New Record" which 
now no longer works in Chrome4.  It works OK in FF and IE, and I can still 
use Ctrl-S for "save" and Ctrl-P for "print" across the board.  I'd also 
like to be able to use Ctrl-T and Ctrl-W amongst other key combinations.
The current situation in Chrome4 appears to be due changes made under issue 
5496 (which also includes  issue 5659 ).  The two main reasons given in these 
issues are slightly slower response when using Ctrl-T instead of button 
click to manipulate browser tabs (5659) , and to stop malicious code 
preventing a user from closing a browser tab (or the browser itself) via 
the keyboard (e.g. by using Ctrl-W).
I feel that not all the changes made are justifiable, as they restrict the 
web page author from using these specific keyboard usability features 
consistently across the major browsers.
I really can't see any good reason for preventing intercept of Ctrl-N or 
Ctrl-T for example.  It's extremely unlikely a malicious page would seek to 
block these, and even if it did, it shouldn’t cause any real problem as far 
as I can see.  I'd have hoped these performance of these could be improved 
without having to reserve these keys, but if not, it's a price worth paying 
for making the web page content itself more usable.  I also can't see why 
Ctrl-W needs to be reserved, in Windows at least, since Alt+F4 is always 
available to close the browser.
I therefore would request that the following key combinations should be 
reinstated as ones that can validly be intercepted (and default actions 
prevented) by client side JavaScript.
Ctrl-N, Ctrl-Shift-N, 
Ctrl-T and Ctrl-Shift-T.
Ctrl-W, Ctrl-Shift-W, 
It would also be useful to have access to the following combinations as 
well, although these aren't handled consistently between FF and IE.
Ctrl-Tab and Ctrl-Shift-Tab.

1.4 KB Download
Also related: Issue 27559
Labels: -Area-Undefined autoclass-3 Area-UI
Using an automated filter to classify this issue into an area...gulp
Status: WontFix
Comment 4 by, Feb 19 2010
bummer that it's a won't fix. constricting developer freedom doesn't seem like the 
right choice to me.  So the choice is to use FF/IE or build a custom chrome and send 
that out to users.  btw, the ctrl-w thing is the worst, I have lost quite a bit of work 
because of it.

Comment 5 by Deleted ...@, Jul 7 2010
I have lost a lot of work due to ctrl+shift+w closing the browser. I was supposed to close a tab with ctrl+w, but my laptop keyboard was slippery so i got ctrl+shift+w by mistake. And this happens a lot in my case.
Comment 6 by, Sep 22 2010
I'm developing a completely web-based web IDE (code editor / project manager), and I've stumbled upon this issue yesterday as well. CTRL-W is the shortcut to close the currently open file in the project, and while I didn't lose any work due to the application's AutoSave, it is still embarassing for Chrome not to support querying certain keys via JavaScript.

So, if this is "WontFix", it clearly means "WontSupportChrome" for an innovative product - which is probably soon to be open-sourced, btw.


Alexander Ewering
instinctive mediaworks

Comment 7 by, Sep 23 2010
Another note: What clearly *is* a bug that needs fixing is that Ctrl-W doesn't even fire the "unbeforeunload" event, so my application can't even ask the user if he/she wants to save the currently open file(s). That makes this problem even more cynical... ;)
Comment 8 by Deleted ...@, Sep 23 2010
You're sure that typo isn't copied from your code? "unbeforeunload" should be "onbeforeunload" right?
I was going to post this issue myself when I found this report. I run a fairly popular website ( which allows users to type foreign characters using keyboard shortcuts with Ctrl. For example, in the Spanish keyboard, Ctrl+N types ñ.

I can bind the Ctrl shortcuts in IE and Firefox just fine, but Chrome always executes the default browser action on Ctrl+NTW, which means that users are prone to accidentally opening new windows/tabs while typing. It's a usability nightmare.

I cannot use Alt shortcuts because Alt is reserved for navigating to anchors with the accesskey attribute, so you cannot really use it in web apps. (Alt+D is also non-overridable in IE.)

I agree with the OP that the security impact of allowing web apps to bind Ctrl+NTW should be minimal. You can always close any malicious page with Alt+F4.

Please reconsider your decision.

Tomasz P. Szynalski
Comment 10 by, Jan 31 2011
As a workaround, you could have your users just tap Ctrl once and not hold it down. I don't want websites to be able to override Ctrl+W, etc.
Thanks, but no, I couldn't. As the user holds Ctrl, repeated keypresses change the character being typed. For example, Ctrl+E types é, but Ctrl+EE types è. Even if that weren't the case, tapping Ctrl would be far less usable.

Consider this:

1. Websites already CAN override Ctrl+W, Ctrl+N and Ctrl+T in IE and Firefox. I haven't seen any website that does so in a malicious way, have you?

2. Furthermore, it is not clear what the purpose of blocking these shortcuts would be. Ctrl+W is rarely used (Alt+F4 is much more popular), so is Ctrl+N (new window). Ctrl+T (new tab) is more useful, but what malicious purpose would be served by blocking it? If I wanted to prevent you from leaving my site, I would just use onbeforeunload (which Chrome permits) to display an annoying dialog box when you try to leave. And indeed thousands of sites do just that, as I'm sure you know.

So there is no need to be afraid of allowing web apps to use Ctrl+WNT shortcuts. Experience shows that websites have little reason to abuse them, and we know that there are much more effective ways to abuse JavaScript in a malicious way.

Tomasz P. Szynalski
In an effort to completely switch from Firefox, I recently patched ajaxterm to work in Chromium.  The result is *almost* useful, except for this issue...  every time I type Ctrl-W in emacs (a 20-year habit for me) it closes my Chromium tab, causing much havoc and rework.  

I also respectfully ask that this be reconsidered from "WontFix".

Also note that in addition to Ctrl-NTW, I second the OP's inclusion of Ctrl-Tab, and Shift-Ctrl-Tab.  

I feel this issue is relevant: . It is a big deal. The fact that this bug is a wontfix is in opposition to Chromium and Chromium OS's goal to allow for a desktop-like experience in web-based applications.

Perhaps a permissions dialog similar to GeoLocation's ( would allow an application to use these reserved keyboard combinations without too much "risk."
52.2 KB View Download
Comment 15 by, Feb 25 2011

For past discussion.
Comment 16 by Deleted ...@, Mar 2 2011

не могу найти “вопросительный знак"

Please, please, reconsidering changing this "WontFix".  I would really like to be able to use Chrome in applications such as shellinabox.
I've resorted to using which lets you at least redfine those keys. 

I wish chrome would just let javascript capture *all* keystrokes like other browsers do.  If paranoid, pop up an alert the first time you visit the domain that's trying to use the keys and allow the user to OK that domain.  Developers that want to make chrome *the* UI to all sorts of varied applications are stymied by this wontfix.

Comment 19 by, Jun 24 2011
Offense intended, but you've really pissed me off as a developer. Thanks, Chrome.
This severely needs to be modified, Chrome has no right to override a web app.
You can't expect us to build desktop class web applications if you purposely go skrewing around with the tools we need to create them.
As a user I always want CTRL+NTW and CTRL+Tab/CTRL+Shift+Tab to have their default browser behaviour regardless of what tab they are on.

1) I wouldn't want to be CTRL+Tabbing through my tabs and suddenly have it stop on a web app's tab because it had overridden it.
2) I wouldn't want to have to switch tabs before pressing Ctrl+NT to open a new window, especially if I'd just switch to my browser without looking at what tab was open.
3) I wouldn't want to have to switch to using my mouse, just to close a tab. Especially on a laptop with a trackpad.
Comment 21 by, Jun 24 2011
A good compromise could be to only allow Ctrl+N/T/W/Shift/Tab overriding when the page is fullscreen.

Of course you want Ctrl+N to open a new window. Except when you're using vim in your browser, then you want it to find the next match (autocompletion) because that's what you're used to. Or when you're using - then you want it to type ñ because there is no other logical shortcut for it.

Look, everyone posting here is aware that overriding Ctrl+NTW has certain undesirable usability consequences. However, there are some legitimate uses where the benefits outweigh the disadvantages.

Finally, allowing webapps to handle Ctrl+NTW will have no negative effect on your browsing experience. Page designers will have little reason to override the default browser behavior, unless absolutely necessary. In fact, you might never come across a website that does. (Malicious use is unlikely for reasons I explained in one of my earlier posts here.)


Tomasz P. Szynalski
As I mentioned earlier, adding a Javascript API extension which app developers are required to call before they can capture all keys would solve all of the unresponsive script problems.

If we're really worried about malicious use, then we can make a Allow/Deny prompt like the one which is used for location data.


"Of course you want Ctrl+N to open a new window. Except when you're using vim in your browser"

"there are some legitimate uses where the benefits outweigh the disadvantages."

The problem is that if it's allowed then it won't only be used on a few sites where it might possibly make sense but also in places where it doesn't make sense, or where users aren't expecting it to be used. By disallowing it users are guaranteed to have consistent keyboard shortcuts that they can rely on. It's only going to frustrate people when they try a site out and then find it's overriden the shortcuts.

"Ctrl+W is rarely used (Alt+F4 is much more popular)"

I use Ctrl+W all the time to close the current tab. I'm sure a large proportion of users do too. Alt+F4 would close the entire window so I'm not sure why you're comparing them.
Comment 26 by Deleted ...@, Jun 27 2011
F**k Crome! not good for web developers
@sam.hasler: But if users would have to give permission to sites via prompt, then there will always be the expectation by the user that these shortcuts will be used by the website.  There would never be an instance where a site could map these shortcuts without confirmation by the user.  

To be completely honest, I'm fairly certain the number of people who use Ctrl+W is extremely small.  I use it every so often, but ordinary users, the type of user who the devs are concerned with, likely very rarely use it.  

"The problem is that if it's allowed then it won't only be used on a few sites where it might possibly make sense but also in places where it doesn't make sense, or where users aren't expecting it to be used."

1. Maybe I haven't thought about it long enough, but I don't think it's something that would be commonly abused. Who would want to override Ctrl+WNT without a good reason? (So far I haven't seen any examples, although it is possible in IE & Firefox.)

2. The fact that a feature can theoretically be used in a frustrating way is not a sufficient reason to disable it. For example, I am frustrated by sites that show you an annoying "Are you sure you want to leave the site?" popup when you try to close them. But I don't believe that this feature should be removed from browsers, because it can be useful in many cases.

Similarly, I could rewrite your argument to argue that websites should not be able to set the color of hyperlinks: "If we allow them to do that, they will use it not only in ways that make sense, but also in ways that don't make sense (e.g. making links hard to distinguish from regular text). By disallowing it users are guaranteed to have a consistent hyperlink look that they can rely on."

3. In my opinion, browsers should try to offer as many features as possible, unless it is demonstrated that for the average user, a particular feature causes more harm than good (example: javascript pop-ups). In the case at hand, it has not been demonstrated. There's just general "but what if websites use it wrong?" talk.
I just realized that Flash automatically prevents these keyboard shortcuts (plus others, e.g. F11) to work. When the mouse and keyboard are focused on a Flash object, pressing (say) Ctrl+T does nothing. In addition to that, the programmer has the option to capture these keys and use them for the Flash application.
Chrome allows Flash, so shouldn't it allow JavaScript developers to do the same?

Please reconsider. Thank you.
I think, there should be an option in the settings to allow web pages to override browser shortcuts, maybe with the three steps "never", "only webapps" and "every webpage". By default i would set it to "only webapps". Webpages which really need this shortcuts can notify the user to allow it. There could also be an option "ask everytime". Everyone would be happy.

> Similarly, I could rewrite your argument to argue that websites should not be able to set the color of hyperlinks: "If we allow them to do that, they will use it not only in ways that make sense, but also in ways that don't make sense (e.g. making links hard to distinguish from regular text). By disallowing it users are guaranteed to have a consistent hyperlink look that they can rely on."

The colour of hyperlinks only affects how that website looks. Overriding shortcuts for browser behaviour can affect the user when they aren't paying attention to which tab they are on. e.g.:

a) with focus on the rightmost tab, trying to close the last 3 tabs, with the middle of those overriding CTRL+W.

The annoying "Are you sure you want to leave the site?" popup at least provides some feedback as to that is going on. If a site overrides CTRL+W because it doesn't want to make it easy for users to leave there would be no indication that the site had done it and the user may attribute blame to chrome.

b) Switching to the browser with ALT+TAB and then trying to open a new window or tab with CTRL+T/N

c) Moving through the tabs with CTRL+TAB 

"browsers should try to offer as many features as possible" that is completely opposite to how chrome was designed. They have tried to remove as many settings and choices from the user as possible by picking sensible defaults or designing it in such a way that there is no need for the user to make a choice.
Maybe the browser window itself shouldn't allow resetting those shortcuts but what about apps? If you have only the app-window shortcuts like Ctrl+Tab or Ctrl+W are (at least in my opinion) not considered critical so allowing the app to override would be a pretty nice feature..
As a data point...

I still close windows with Ctrl-W, but less often now that Outlook2007
doesn't support Ctrl-W for close.

I use both Firefox (which allows overriding Ctrl-WNT) and Chrome
(which doesn't).  (on WinXP, Ubuntu and OSX)

I tend to use Firefox more than Chrome, because *this issue* makes
Chrome unusable with Anyterm or Ajaxterm.

I have never *ever* been annoyed or inconvenienced by an web page or
application overriding Ctrl-WNT... let's be honest, few applications
need to do this, and it's not worth doing maliciously.  The apps that
need to do override, though, *really* need to do it.   A terminal
emulator that doesn't capture control keys is useless.

Bottom-line, I argue that web apps only override Ctrl-WNT for good
reason, that there *are* good reasons to do so, and thus Chrome
*should* support overriding these sequences.

Much of your post is a restatement of the possible annoyances that can be caused by websites overriding Ctrl+WNT, so I'll get to the only new argument in your post:

"If a site overrides CTRL+W because it doesn't want to make it easy for users to leave there would be no indication that the site had done it and the user may attribute blame to chrome."

It's not worth capturing Ctrl+W for that purpose because it would affect a minuscule proportion of users (almost all users close tabs using the mouse). The baddies have been able to do it in IE/Firefox for a long time -- and they don't.

BTW, Chrome already makes it possible to screw up a site in countless ways, many of which might be attributed to Chrome by users, for example:

- I can make regular text that looks like a hyperlink (underline+color), but when the user clicks on it, nothing happens
- I can create a JavaScript popup with an error message
- I can tamper with browser history or do redirects that will render the Back button useless

In all of these cases, the average user is not going to know whether it's my website's or Chrome's fault. Nor do I think that the user cares.

I (and others) have given CONCRETE examples how enabling Ctrl+WNT would benefit users. The other side is just telling scare stories about how websites might abuse this if it is allowed, without showing that anyone might ACTUALLY want to do that. Furthermore, we know that other browsers have supported this for a while, and there has been no abuse.

So unless you can give a REALLY good argument why this feature will suddenly start to get abused when Chrome allows it, I think further discussion will be of little value.

Comment 35 Deleted
Note that the original reason for having the CTRL+WNT keys interpreted by the browser directly is that tabs running expensive Javascript would block Ctrl-W from working, even if the web app did not catch Ctrl-W.

This is why having the app request access to these keys before getting them would largely solve this issue.


A user dialog would certainly solve the problem, but isn't there a simpler solution? What happens if you put some expensive JS in an onbeforeunload handler, and then try to close the tab? How does Chrome handle it?

One idea is that the browser could give the webpage a certain small amount of time to handle a keystroke and, if there's no reaction, close the tab.
@tszynalski: I believe Chrome has a response timer.  If the tab doesn't respond with X amount of time after the user closes it, then it kills the tab.  
Comment 39 by Deleted ...@, Jul 2 2011
I'm a heavy keyboard user and almost exclusively use ctrl+w to close tabs in practically all applications I use (most notably browser & eclipse). I'm building a web application that initially targeted firefox/chrome, but it also uses tabs on the page itself. I want to support what users (including myself) are used to, which is ctrl+w to close a tab in the web application.

That said, I refuse to remap the default combination to something no one is used to.
Removing the ability to intercept it because of malicious uses is absurd as in all my years of firefox browsing only one thing has bugged me with such an issue: flash; not some javascript application. Luckily we have this magical device called a "mouse" that can sidestep such malicious brilliance.

Additionally I would like to emphasize that as mentioned above, only advanced users tend to use keyboard shortcuts which means malicious sites have little to gain by blocking these. Unlucky for me perhaps that the advanced users are my target audience for this web application. Well there's always firefox ey?
Comment 40 by Deleted ...@, Jul 4 2011
Could somebody confirm that this issue also applies to CTRL+mousewheel? Chrome seems to execute default page zooming instead of specific JS code no matter what I try. 

Comment 41 by, Jul 17 2011
Could someone create a flash application to capture *all* keystrokes
and route them to a javascript function?  I think that would solve our

Also, I would love to have unfettered access to the clipboard as well,
adding and removing data from it at will via javascript.  I think this
is also in the domain of flash.

My application is a specialized editor, and I am getting thwarted by
chrome's restrictions.
Providing access to the clipboard is a security risk.
Comment 43 by, Jul 22 2011
At least, Ctrol-NTW should be available for js in "fullscreen mode".
Those keys are not applicable in fullscreen anyway.
I'm trying to port our application to chrome but this bug is a big problem, Chrome is supposed to support application development on the web but how can we do it if we have no access to those standard shortcuts ? The security argument is ridiculous. Thanks.
Adding an option to enable/disable locked hotkeys, even if only set without a gui, should be possible. At least those who need this functionality will have it available and the default will protect users from malicious websites.
Comment 46 by Deleted ...@, Dec 5 2011
hurry up and fix this shit google!
Yes please!  This bug has been here for almost 2 years now!  It's crippling.
Comment 48 by, Dec 6 2011
I fear the Status: WontFix has something to do with the disappointing development.
Jup he's right. So either someone brings new, better arguments(and not just "this works in other browsers") or I guess this will stay closed as wont fix. Even though a few people complained about this I don't see this as useful for the interface. Imagine your Windows/Linux/Mac apps would interfere with standard system behaviour like [Alt] + [F4] in Windows... 
Maybe setting status won't fix on a major problem was not a good idea.... The clipboard issue could be a security risk but for Ctrl+W, Ctrl+N, Ctrl+T it's ridiculous.... 
Ctrl+W -> you can close the window with the mouse, like any basic user does...
Ctrl+N Ctrl+T -> you can not open a new window or a new tab , is that really a major security risk ?

I got potencial new chrome users if this trivial problem is solved and I guess lot of web based enterprise application are waiting for this fix...
> Imagine your Windows/Linux/Mac apps would interfere with standard system behaviour like [Alt] + [F4] in Windows...

Are you saying it is *impossible* for apps to mess with "standard" keys?  What if an application couldn't catch, say, the F1 key — what if that always brings up the Windows "Help and Support Center" — wouldn't that be pissing?

I honestly can't see any good reason for limiting us this way.
@maik.kulbe ok, give us arguments for not implementing this behaviour.... "we won't fix" is not an argument. And yes I think you can capture Alt+F4 on your application and I don't see any reason to forbid this.... The web is not just websites it's applications too and professional applications require access to those shortcuts to comply with ergonomic standards
There is only one argument : we can use firefox to develop professional web based applications and we can not use chrome.
Sure you can capture Alt+F4 via the windowClose event but this is ment for dialoges like the ones saying "Unsafed changes will be lost". You would need a REALLY clear message to the user if an app wants to catch those keys. Imagine some black-hat would write some JS that triggers those events or overrides them with something completely different. Where's your ergonomic standards then..?
Comment 54 by, Dec 6 2011
@maik.kulbe: The point is not that you can write an un-ergonomic app with these shortcuts. The point is that you can't write an ergonomic app without them.
Well when we have these arguments where I work, usually the answer is "the user should decide". So maybe the settings page could have a user setting where those afraid of evil world dominators taking over their computers and those who use their browser for eight hours straight for work can set this hotkey behavior to whatever they feel comfortable with. Just let them choose between "Don't allow overriding any browser hotkeys", "Allow most except Ctrl-W, Ctrl-T and Ctrl-N" and "Allow overriding all browser hotkeys".

And then for new users the first time they encounter an attempt by a website to intercept one of these holy combinations, it would ask what to do in one of those yellow bars.

If you want to get really fancy, you might even allow setting site-specific rules based on the setting above. But really, anything that gives Ctrl-WNT for those of us who want it.

That's just my two cents.
@oskari.g wouldn't that be better as an extension permission? It is really only useful for webapps and those should be provided as CRX(-less) Chrome Apps. I mean, I don't see, why a web page would *ever* need this..

@jimo maybe you should write a detailed feature request for that with some studies, etc.(and also pointing to this Issue) so everybody can see why you need this in Chrome. 
Comment 57 by, Dec 6 2011
@maik.kulbe: If you read the previous comments to this issue, you will find examples of use cases when people need these keyboard shortcuts on a web page.
@maik.kulbe :  Imagine some black-hat would write some JS that triggers those events or overrides them with something completely different.

That's exactly why we tell you that other browsers allow this. Do you have ever seen website doing this ? Is that reality or imagination ? On one side you got people that tell you that you can't write good application with chrome because of this bug and on the other, people afraid about imaginary evil websites implementing behaviors that none of there targeting audience use... You should implement the "standard" behavior, it should be easy and if one day imagination become reality, you could implement an extension permission like for popups.
The black-hat JS triggers issue is a red herring. The real reason this was disabled was due to

I think this is as far as this issue has gone:

This seems to affect extensions too, by the way. For example both Vrome and Vimium (they are extensions that try to give Chrome vim-like behaviour) can't listen to CTRL-P and CTRL-N, which in Vimperator (their Firefox equivalent) triggers 'previousTab' and 'nextTab' respectively.

Even if you don't allow rebinding these keys for webapps (I think you should, but it's your call) perhaps you could consider allowing it for extensions?

Comment 61 by, Dec 9 2011
This is bull shit. 
Safari and Firefox can overwrite command+n without opening up a new window, why can't Chrome. If you want to promote web app, fix this non-sense.
yet another app that doesn't work because of this bug:

google, can you please fix this! PLEASE?!

Comment 63 by, Feb 5 2012
is Ctrl-Shift included here too? and if so then why?

Several touch-typing tutorial apps fail because of this bug. The stubborn wontfix status here is immature. People have already brought up reasonable means of fixing this that address both sides of the issue.
I've just come across this 'bug' having spent four days moving the various family machines over from the increasingly bloated Firefox to Chrome. For me the biggest problem is that it breaks Logmein (and I'm guessing a few other remote desktop solutions too).

As the sole support person for the household I'm regularly connecting to others' PCs and taking control of their browsers where my muscle memory makes regular use of CTRL-T and CTRL-W for manipulating tabs. Having CTRL-W close the whole Logmein session tab instead of the tab on the remote machine is an absolute nightmare that has led to more swearing and hair-pulling over the last 24 hours than you could imagine. It will it take weeks of behavioural reconditioning to get me back to using the mouse.

I've too much time invested in the switch-over now to consider going back to Firefox but rest assured had I known beforehand about this incredibly bad design decision on the part of Google I would never have switched in the first place. I'll certainly be letting all my power-user friends know. This could well be a deal-breaker for many.

Please reconsider changing this behaviour either by default or as an under-the-hood option.
I'm working on a pet project — that's a Lisp system in JavaScript, and it includes an environment for editing code based on Ymacs [1].  Every now and then I press CTRL-F4 to close the current buffer, only to find that it kills the whole window and I have to start over.  Aaaargh!

BTW Chrome is simply the best on this, it's faster than other browsers by orders of magnitude.  It's just that when I'm editing code my brain and hands are setup to different keybindings than when I'm doing ordinary web browsing.  There are some shortcuts that I totally need to be able to catch, otherwise it's just not as good as it could be.

Come on people, please fix this!  “WontFix” is just lame, please allow the user to decide!

Comment 67 by, Feb 25 2012
ah ymacs... That editor is a masterpiece Mihai!  I can't use it due to this chrome bug: ctrl-w has bit me too many times as it's ingrained finger memory, and all my work goes up in a poof of smoke, and ctrl-n is just annoying as all get out.

BTW, I love your UglifyJS, I use it all the time.  I'm sure it's in the top 100 of watched github projects.  If google ever offers you a position, get them to fix this bug before accepting :-)

Comment 68 by, Mar 15 2012
Similar to the OP, I'm developing a database interface for which Ctrl+N is a shortcut to add new records and Ctrl+S is a shortcut to save a record.  I am able to capture Ctrl+N in Firefox, Safari, Opera and Internet Explorer.  Only Chrome does not enable me to capture Ctrl+N.  In contrast, I can capture Ctrl+S in all the mentioned browsers, including Chrome.

It seems arbitrary and misguided to allow capture of some control keys and not others.  The argument with Ctrl+N seems to be that preventing a user from opening a new window is too disruptive to allow.  How is that more disruptive than preventing the display of the save dialog with Ctrl+S?  I don't think it is.  The same can be said for Ctrl+P and the print dialog.  *Many* legitimate reasons for capturing Ctrl+NTW have been discussed in this thread.  It is insulting to developers to ignore this discussion and stubbornly stick to "WontFix".

When 4 of 5 browsers support a particular behaviour, I think it's fair to say that the standard is what the 4 browsers support.  It used to be that Microsoft was the company that refused to follow web standards.  At least with Microsoft's blunders, there was always a transparent (to the user) way to workaround the problem.  Not so here.  The only option is to use another control key.  For some of the other applications discussed here, there is no solution.

For my application, I'll continue to use Ctrl+N in all browsers except for Chrome.  I'll use Ctrl+M in Chrome and explain why in the user's manual.

Google: Please reconsider your decision and fix this!
Comment 69 by, Mar 15 2012
This is being worked on.

See also:

Comment 70 by Deleted ...@, Mar 22 2012
This issue has been raised so often (mostly all merged into the above "being worked on" thread.

A lot of good ideas have been suggested.

It's frustrating that the conclusion for all of this is a bare-minimum fix.

[sarcasm]I'm looking forward to every second page I visit requesting I install it as an app before it will work properly[/sarcasm]
Comment 71 by Deleted ...@, May 7 2012
Are you Chrome guys going to fix the "e" accent mark problem?
Comment 72 by Deleted ...@, May 30 2012
Fix this problem.... please!!
It would so much more efficient to find a compromise, as of the several that have been suggested in earlier comments; as it is, my Spanish courses online are extremely hard to take without being able to type the letters correctly. 
Comment 74 by, Aug 29 2012
Add another dev who /WAS/ 'Chrome or Nothing' and now I'm feeling some serious rub on this issue.

Nobody has justified this 'solution' that everyone is calling a 'problem', and launching the page as an application (only an option because I'm developing local app pages) does not solve the issue, in fact it seems to have a random result depending on which keys you're trying to re-purpose.

Now I am stuck because I've been very strict on Chrome use with my app, ignoring differences in Firefox..  However the glitches with Firefox are easier to fix than this huge hole in my app.
Folks concerned about this should also see #119881.
Project Member Comment 76 by, Oct 14 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.
Project Member Comment 77 by, Mar 11 2013
Labels: -Area-UI Cr-UI
Sign in to add a comment