We Keep Coding

Any way to prevent/disable CTRL + [key] shortcuts in the browser?

I know a lot of people will be angry about this being asked but...
I have a game using WebGL and the Pointer Lock API. Due to the nature of a lot of games having 'crouch' on CTRL I was wondering if there was any possible way to stop browser shortcuts like CTRL + S and CTRL + W...
At the moment I'm having to harshly disallow controls to have any CTRL key in them. I have set 'crouch' to C which is also common but I also have ideas about making a MMORPG-style game where you would have several action bars of abilities and a lot of combinations wouldn't be possible due to CTRL not being viable.

Note: In Chrome Ctrl+W is "reserved", use window.onbeforeunload
Note: Chrome requires event.returnValue to be set
In this code document.onkeydown is used for old browsers and window.onbeforeunload is used to Chrome and Firefox
Try this (disable Ctrl+W and Ctrl+S):
window.onbeforeunload = function (e) {
// Cancel the event
e.preventDefault();
// Chrome requires returnValue to be set
e.returnValue = 'Really want to quit the game?';
};
//Prevent Ctrl+S (and Ctrl+W for old browsers and Edge)
document.onkeydown = function (e) {
e = e || window.event;//Get event
if (!e.ctrlKey) return;
var code = e.which || e.keyCode;//Get key code
switch (code) {
case 83://Block Ctrl+S
case 87://Block Ctrl+W -- Not work in Chrome and new Firefox
e.preventDefault();
e.stopPropagation();
break;
}
};

Flex disable Safari keyboard shortcuts

I have a Flex app running on a web page, and I want to use the Command+← key combination to trigger certain actions in the app. This is fine on most browsers, but on Safari, the browser intercepts this keyboard event and causes the browser "back" event instead. Is there a way, either through Flex or via JavaScript elsewhere on the page, that I can tell Safari not to do that?

Short answer, it's a (little) known bug on non-mac versions of safari. You can't reliably block all shortcut keys. Perhaps if you were more specific about what other shortcuts you're trying to block? Maybe some of them will work. e.g. cut paste copy have their own special methods of blocking. (Although it seems like you probably already know that.)
Are you using something like this?
function blockKeys(e) {
var blocked = new Array('c','x','v');
var keyCode = (e.keyCode) ? e.keyCode : e.which;
var isCtrl;
if(window.event)
isCtrl = e.ctrlKey
else
isCtrl = (window.Event) ? ((e.modifiers & Event.CTRL_MASK) == Event.CTRL_MASK) : false;
if(isCtrl) {
for(i = 0; i < blocked.length; i++) {
if(blocked[i] == String.fromCharCode(keyCode).toLowerCase()) {
return false;
}
}
}
return true;
}
You're not the first to get hit with this bug on here

How to override Ctrl + N in firefox to launch AJAX

Note: Juan Mendes answer is the selected answer because it had the most useful response to my situation. Though AxGryndr also had some useful information. Read both answers and they are both good for different situations. Thank you both for helping with this.
I already asked a similar question about this here which did solve the first part of my problem now I have another. I want the Ctrl + N to launch a script that contains an AJAX but once I run the .get function it cause the default to launch. Does anyone know a work around for this.
This fiddle has some code that shows my problem. Here is some of the code.
function checkkey(e)
{
if(e.ctrlKey && e.keyCode == 'N'.charCodeAt(0) && !e.shiftKey && !e.altKey)
{
try{e.preventDefault();}catch(ex){}
var m_objXMLHttpReqObj = new XMLHttpRequest();
m_objXMLHttpReqObj.open("GET", "", false);
m_objXMLHttpReqObj.send();
}
}
JSFIDDLE

Your code was not preventing the default behavior
function checkkey(e) {
if(e.ctrlKey && e.keyCode == 'N'.charCodeAt(0) && !e.shiftKey && !e.altKey) {
e.preventDefault();
// Now send your AJAX
It also seems that AJAX is interfering with the ability to stop the default behavior. You were trying to send a synchronous AJAX request (don't ever do that, it will halt the browser) and you weren't giving it a URL to go to (triggering an error). As soon as you change your settings to properly give it a URL and to make it asynchronous, then it does work in FF.
Here's the working code
function checkkey(e) {
if(e.ctrlKey && e.keyCode == 'N'.charCodeAt(0) && !e.shiftKey && !e.altKey){
e.preventDefault();
var m_objXMLHttpReqObj = new XMLHttpRequest();
m_objXMLHttpReqObj.open("GET",
// URL to go to
"/echo/html/",
// Asynchronous
true);
m_objXMLHttpReqObj.send("");
}
}
However, in Chrome (it may not be of use to you, but to others who read this answer), if you add a console.log at the top of your handler, you'll see that the handler never gets. Therefore, Chrome doesn't even let you see the CTRL+N combination and you can't do anything about it. Just like Windows applications don't get notified of CTRL+ALT+DEL
If the application has to work for multiple browsers, my suggestion is to use a different combination like ALT+SHIFT+N, you really don't want to take over the basic browser shortcuts.

I believe your issue is that you are checking for a keypress and performing your action too late after the keyup. If you change your code to bind to the keydown of Ctrl+N I think your would be able to get the desired result. Something like:
var pKey
$(function() {
$(window).keydown(function(e) {
if(e.which == 17) {
pKey = e.keyCode;
}
else {
if(pKey == 17 && e.keyCode == 78) {
e.preventDefault();
console.log(e);
}
}
});
});
I added the global variable to capture the Ctrl key down which is keycode 17. I then capture the keycode 78 on the second keydown which is the N. Prior e.preventDefault() was not enough to prevent the new window so I had to add the extra lines for e.stopPropagation(), e.stopImmediatePropagation() and the console.log(e) can be removed. As Juan M has mentioned the others are no longer needed so I have updated the code to not include them.
Note: Firefox made a change in key biding priority. It use to be System>Website>Firefox however it seems people were complaining about websites that hijacked short cuts so the priority has changed to be System>Firefox>Website which means even if your website binds Ctrl+N the priority of Firefox for a new windows takes over.

How can I prevent a custom key bind from making a noise?

Rather vague title, I know, but I'm binding a custom key event to the document object to catch AltR combination keypresses, like this:
document.body.onkeydown = function(event){
event = event || window.event;
var keycode = event.charCode || event.keyCode;
if (keycode === 82) {
if (event.altKey) {
if (!canReload) {
canReload = true;
window.location.href += "#doGreaseRefresh";
} else {
canReload = false;
window.location.href = window.location.href.replace("#doGreaseRefresh", "");
}
return false;
}
}
}
The code runs as expected but also produces a rather annoying "beep" sound as well. How can I prevent this? return false didn't prove to be the answer, so I'm wondering if it's even possible.
Oh, and if you're wondering, this is in a Chrome userscript (Content script) to refresh Stack Overflow's home page every 10 seconds if I've pressed AltR, and to stop refreshing once I've pressed AltR again. :)

Not being able to stop the beep is apparently a bug in Chrome: http://code.google.com/p/chromium/issues/detail?id=105500. return false works in Firefox without a beep.
Cheers-

As ZachB points out, this appears to be a bug with Chrome.
To work around this annoyance:
Go into the Windows control panel.
Select Sounds or System Sounds
Assign (None) for the sound of the Default Beep.
(I like to do this anyway, since it's 50 times more annoying than it is useful).

Is there a way to detect find on the page searches in javascript

each browser has find on page functionality (ctrl+F). Is there a way to detect user searches in javascript so that I could attach additional actions.

Here is a solution which can account for alternative page find situations (ex. Command+F, '/' on Firefox). It checks for any of these keypresses and sets a timer when they occur. If the window is blurred soon after, then it is assumed that the Find dialog is showing.
Disadvantages: does not account for the "Find" dialog being launched via the menu. I don't see any way to be sure about this part, since (as far as I know, at least) browser UI is off-limits to Javascript running inside the DOM.
var keydown = null;
$(window).keydown(function(e) {
if ( ( e.keyCode == 70 && ( e.ctrlKey || e.metaKey ) ) ||
( e.keyCode == 191 ) ) {
keydown = new Date().getTime();
}
return true;
}).blur(function() {
if ( keydown !== null ) {
var delta = new Date().getTime() - keydown;
if ( delta >= 0 && delta < 1000 )
console.log('finding');
keydown = null;
}
});
jsFiddle, tested in Chrome, Safari and Firefox

You could do (to detect whenb a user press ctrl+f):
window.onkeydown = function(e){
if(e.keyCode == 70 && e.ctrlKey){
//user pressed ctrl+f
}
Fiddle here: http://jsfiddle.net/d8T72/

Of course you can try to hook into ctrl+f or cmd+f shortcut, but even if that works on "some" browsers, that way you only would know that an user pressed that shortcut and is most likely to search for something.
If the browser allows to overwrite that shortcut, you could further block the default behavior and implement your own search logic on the site. But that is considered most times as very bad practice. Overwritting native browser behavior is pretty pretty bad.
On the other hand, there is no "event" which gets triggered when a browser executed a search process. In short words, no, there actually is no way to detect or hook into a search process with javascript (if there is one, it's never gonna be cross browser compatible).

As initially suggested by #Nicola Peluchetti, here is a slightly improved version by feature sniffing:
window.onkeydown = function(e){
var ck = e.keyCode ? e.keyCode : e.which;
if(e.ctrlKey && ck == 70){
alert('Searching...');
}
}
Browser search test case »