I navigate with Ctrl+n,p,f,b (readline/Emacs keys), so that I don't have to move my hands too much and get RSI again. Is there a way to disable Ctrl+b being hotkey for bold?

Note that this is not just an Emacs thing. Standard web browsers, like Firefox and Chrome, use things like Ctrl + K and Ctrl + L to navigate to the Google search bar and address bar respectively.

  • 2
    These are called "access keys", and are implemented with the "accesskey" attribute. You might like to add this as a tag.
    – mjs
    Nov 14 '09 at 17:46
  • 8
    Agree. overriding ctrl bindings should never be done haphazardly. Apr 22 '11 at 14:54
  • 32
    +1 please add a preference to turn it off, or change the keys to something that doesn't interfere, or just remove the feature altogether. I run into this problem several times a day, and it's starting to piss me off. Dec 25 '11 at 20:28
  • 1
    In Firefox I often usek Ctrl-k to navigate to the Google search bar. In Chrome I often use Ctrl-l to navigate to the address bar. I hate that I cannot use these while asking or answering a question. Feb 16 '12 at 16:32
  • Historically, preferences are frowned upon. Also, many more people want the key bindings than don't want them, so it's likely that you'll have to come up with a user-side solution such as a userscript in order to overcome this issue.
    – Pollyanna
    Feb 16 '12 at 16:53
  • 9
    @AdamDavis "many more people want the key bindings than don't want them" Do you have any evidence to back up that claim? Feb 16 '12 at 17:06
  • 1
    @MichaelMcGowan Nope. Other than it was included by default in the WMD editor, we've had it for years, and questions suggesting changing or removing them never get more than a handful of votes. If it were not widely valued, or if it regularly got in the way of people's usage of the site, it would get a lot more scrutiny every time this came up. This request is nearly 3 years old and only has 18 supporters, out of millions of Stack Overflow users, who would surely complain if it was an annoying problem.
    – Pollyanna
    Feb 16 '12 at 17:17
  • 1
    @MichaelMcGowan - control-b to make text bold is I think a much, much more common operation than whatever crazy emacs voodoo OP is talking about. Control-b for bold works in MS Word, Gmail, Google Docs, etc. Adam Davis is most likely right in his assertion, but I doubt anyone has stats to back it up. Feb 16 '12 at 17:17
  • 8
    @AdamRackis Neither Gmail nor Google Docs (Chrome/OS X) does anything special with Ctrl-B for me. Contrariwise, does any editor without this feature have people requesting it? Wikipedia doesn't work like this, nor does Blogger, Facebook, Twitter...
    – mjs
    Feb 19 '12 at 9:15
  • 3
    The CTRL + H is also annoying, since muscle memory expects character deletion (instead you get the Heading shortcut).
    – Blaz
    Nov 20 '12 at 10:48
  • I should add to this. The 'escape' key is mapped to 'browser back'. I pressed it to cancel a search-in-page operation. Annoying.
    – Joe
    Dec 27 '12 at 21:11
  • 5
    Ctrl-B for moving the cursor back is not "Emacs Voodoo" as suggested above, it's a standard keyboard command in macOS that works everywhere. Well, except for SO. Oct 27 '17 at 9:22
  • 1
    Agreed, Emacs keys works absolutely everywhere in Unix except browsers.
    – Thomas
    Oct 28 '17 at 18:17
  • 1
    It does work even in browsers. It works in the address field and in every text input field on every website I use in Safari, Chrome and Firefox. Stack Overflow (and the other Stack Exchanges) is literally the only place for me where Ctrl-B does not work. Oct 30 '17 at 13:02
  • 6
    I use Ctrl-N, Ctrl-P, Ctrl-B, Ctrl-F, Ctrl-A, and Ctrl-K in macOS in all kinds of applications and on all kinds of websites in different browsers. For me these commands just work everywhere out of the box. Only on Stack Overflow Ctrl-B and Ctrl-K do not work because they remapped them without an option to disable that. Oct 31 '17 at 15:38


The correct answer to the above yes/no question is "no".

I do appreciate the other answers suggested here. They offer creative workarounds, and I appreciate the thought people put into coming up with them.

But hacking your browser via "user scripts" or "bookmarklets" isn't really what's being asked for here. Even most developers -- let alone ordinary Stack Exchange users -- are not aware of such options, much less how to install and use them (and evaluate their security risk, etc.). Furthermore, such solutions will likely be brittle (not future-proof).

Think about it this way: If a user had asked "How do I change this shortcut?" and one of the responses was "Here's a Linux kernel patch I wrote for you," would you accept that as an answer? I'd upvote it (thanks for the effort!), but I wouldn't accept it.

A proper solution to the OP's problem would be a built-in SE preference to disable these frustrating hotkey settings permanently. Until that solution exists, the answer to this question is "no".



javascript:(function(a,p){function i(e){e.stopPropagation()};p[a]('keydown',i,!0);p[a]('keypress',i,!0);p[a]('keyup',i,!0);})('addEventListener',$('#wmd-input').parent()[0]);

User Script:

// ==UserScript==
// @name           Cya WMD shortcuts
// @namespace      Rob W
// @version        1.0
// @match          https://stackoverflow.com/*
// @match          https://*.stackoverflow.com/*
// @match          https://superuser.com/*
// @match          https://meta.superuser.com/*
// @match          https://serverfault.com/*
// @match          https://meta.serverfault.com/*
// @match          https://askubuntu.com/*
// @match          https://meta.askubuntu.com/*
// @match          https://*.stackexchange.com/*
// @match          https://answers.onstartups.com/*
// @match          https://meta.answers.onstartups.com/*
// @match          https://stackapps.com/*
// @run-at         document-end
// @grant          none
// ==/UserScript==

(typeof unsafeWindow !== 'undefined' ? unsafeWindow : window).$(function() {
    var p = document.getElementById('wmd-input');
    if (!p) return;
    p = p.parentNode;
    function ignore(e){e.stopPropagation();}    
    p.addEventListener('keydown', ignore, true);
    p.addEventListener('keypress', ignore, true);
    p.addEventListener('keyup', ignore, true);

Technical details

  • In the W3C event model, JavaScript events are fired in two ways:
  • Capture (The events are fired, from the top of the document to the target)
  • Bubble (The events bubble from the target to the top of the document).
  • In wmd.js, the events are bound using addEventListener, in the bubbling phase.
  • The event is added to the parent node of the element, with the capturing flag. Inside the event listener, event.stopPropagation(); is called, to stop the event from propagating further.
  • As a result, all WMD shortcuts are disabled.

Chrome extension

  1. Create a directory, and store the following two files in it.
  2. Visit chrome://extensions/
  3. Enable Developer mode
  4. Click on the button Load unpacked extension....
  5. Select the directory from step 1.


    "name": "Cya WMD shortcuts",
    "manifest_version": 2,
    "version": "1.0",
    "content_scripts": [{
        "js": ["contentscript.js"],
        "matches": [


var p = document.getElementById('wmd-input');
if (p) {
    p = p.parentNode;
    var ignore = function(e){e.stopPropagation();};
    p.addEventListener('keydown', ignore, true);
    p.addEventListener('keypress', ignore, true);
    p.addEventListener('keyup', ignore, true);


  • PS. Between the creation of this question and this answer, this feature request has been approved. Ctrl+shift+* and Ctrl+alt+* key combinations are not affected, by default.
    – Rob W
    Feb 23 '12 at 17:57
  • @blahdiblah Not tested, but you could insert if(e.ctrlKey) before e.stopPropagation(); so that the script is only activated for Ctrl + * key combinations.
    – Rob W
    Oct 5 '12 at 12:40
  • As per your suggestion, changing i(e) and ignore(e) to ignore(e){e.metaKey && e.stopPropagation();} removes the problematic keyboard shortcut behavior, but doesn't trigger a captcha all the time.
    – blahdiblah
    Oct 8 '12 at 19:11
  • 1
    @RobW thanks, this is fantastic! i use cmd+L compulsively to to go the location bar in chrome on a mac, and it drives me batty that SE thinks its a good idea to override default shortcuts. cmd+R works now too, to refresh the page.
    – Jeff
    Apr 1 '13 at 3:17
  • @Jeff I am actually used to Ctrl+L for links. I've got your issue with Chrome's Developer tools: In the console, Ctrl + L is overridden. I've found that Ctrl+K focuses the omnibar with search. Then it's a matter of entering the keywords (if you were really going to search) or hitting backspace and type the full URL to continue.
    – Rob W
    Apr 1 '13 at 8:06
  • great help, in Firefox/Vimperator the webpage Ctrl+I shortcut interferes with Vimperator's edit-in-external-editor shortcut. In some Firefox versions this results in inserting a emphasized text before opening gvim - in current versions gvim is completely blocked. Exorbitantly annoying. As a quickfix opening your booklet code via ESC :o works fine in Vimperator. Jan 12 '14 at 11:02
  • Bookmarklet does not work anymore with current so site/Firefox 27. Apr 12 '14 at 7:24
  • 2
    The script mostly does not work in Chrome on MacOS. The editor textarea id seems to be wmd-input-52143651 instead of just wmd-input, with a specific number for each instance.
    – chqrlie
    Mar 15 '16 at 1:42
  • @chqrlie You can use this two line modification var wmdInputId = document.querySelector('[id^="wmd-input"]').id; var p = document.getElementById(wmdInputId); . Added in answer too. Apr 19 '17 at 9:18
  • 1
    I packaged your extension for the chrome store
    – Boris
    Apr 20 '17 at 20:40
  • When you press "Edit" on an answer, that creates the textbox then and there, so you'll need to click your bookmarklet again to disable the keys. My extension listens for when new elements are added to the page, so it just works(tm)
    – Boris
    Oct 5 '21 at 2:23

I feel for you, as I have a similar problem... if not worse :-(

On contemporary Hungarian keyboards, some special characters are mapped to key combinations involving the Right Alt (aka AltGr) key. Such as

  • [ to RightAlt+F,
  • ] to RightAlt+G ...which opens the "Insert Image" dialog on SO,
  • { to RightAlt+B ...which evokes strong text on SO,
  • } to RightAlt+N.

Do I need to explain how terrible it is to try to write e.g. Java code with this keyboard mapping? Lately I realized that the Search box doesn't have these mappings - so if I need a closing square bracket or an opening curly bracket (and there is no code snippet around in the actual post to copy from), all I need is to switch to the Search box, type the character, select it, Ctrl+X, back to the Editor box, Ctrl+V...

Even though this is not an answer to your question in the strict sense, at least (hopefully) it shows that this problem is not as marginal as it may seem at first sight.

  • 3
  • 5
    You're not supposed to use keyboard shortcuts at all. In many systems for handicapped users shortcuts are mapped to a single key (e.g. d to delete active tab, f to follow links, i to start typing). Stealing these shortcuts successfully traps such users and they can't continue their work without someone helping them to close the website.
    – cprn
    Jan 19 '16 at 15:35

I made an open source Chrome extension for this



Here is Rob W's script, updated to only block cntrl-* and fixed so that it works with NinjaKit which is a Safari extension for running user scripts. Re-did it for this question on Ask Different

NinjaKit: https://github.com/os0x/NinjaKit


// ==UserScript==
// @name           Cya WMD shortcuts
// @namespace      Rob W
// @version        1.0
// @include          https://apple.stackexchange.com/*
// @include          http://stackoverflow.com/*
// @include          http://superuser.com/*
// @include          http://meta.superuser.com/*
// @include          http://serverfault.com/*
// @include          http://meta.serverfault.com/*
// @include          http://askubuntu.com/*
// @include          http://meta.askubuntu.com/*
// @include          http://*.stackexchange.com/*
// @include          http://answers.onstartups.com/*
// @include          http://meta.answers.onstartups.com/*
// @include          http://stackapps.com/*
// @run-at         document-end
// @grant          none
// ==/UserScript==
(function () {
    var p = document.getElementById('wmd-input');
    console.log("wmd-input:" + p);
    if (p) {
        p = p.parentNode;

        function ignore(e) {
            if (e.ctrlKey) {
        p.addEventListener('keydown', ignore, true);
        p.addEventListener('keypress', ignore, true);
        p.addEventListener('keyup', ignore, true);
  • Only started working after deleting the "Demo" script. Safari 6.0.5.
    – Blaz
    Oct 13 '13 at 10:22
  • 2
    This no longer works. Either something in stack*'s HTML/JS has changed or something in the browser has changed, but as of 1/30/2015 and Safari 8.0.3, this no longer works... I hacked on it for a while but couldn't beat it into submission before giving up.
    – ipmcc
    Jan 30 '15 at 13:14

With Firefox 27 the already posted Greasemonkey scripts and bookmarklet don't work.

The bookmarklet used to work, but it doesn't anymore.

What does work is using anti-keygrabber.user.js (blog entry). In case it does not contain all keycodes you want to be excluded from being grabbed by a webpage you can easily add them.

For example to also exclude Ctrl+I you just have to add:

case 73:

to the first switch statement:

switch (e.keyCode) {
  case 87: // W - close window
  case 84: // T - open tab
  case 76: // L - focus awesome bar
  case 74: // J - open downloads panel

Most likely there is; check in your browser's settings (or at least tell us what browser you are using).

If there isn't you can easily create (or have someone create here on meta) a greasemonkey script to remove the accesskey="" attributes from HTML tags. Again, not all browsers support greasemonkey (Firefox and Chrome do, possibly others do too).

If you are asking for some kind of user setting in your account page then I'm fairly sure it's not going to happen, sorry. Very very few people "navigate" web pages using emacs keys (in fact I find this kinda funny :P) and when it comes to user interfaces less is always better: you don't want to offer 5 thousand options to your user when the average user cares about 1 or 2.

  • 7
    I don't navigate the page with emacs keys. Just the textboxes. I agree, less is better. Which is why I don't understand why SO takes over ctrl-b et.al.. It's horrible. Why would I want to use arrow keys or the mouse? Oh well, I guess I'll have to look into a greasemonkey script. Hmm... there are no accesskey attributes that I can see.
    – Thomas
    Apr 7 '10 at 18:36
  • 1
    +1 for preferences setting to disable accesskeys in textboxes. Apr 15 '10 at 3:08
  • You say: "Very very few people "navigate" web pages using emacs keys". First, I think you're wrong. On the Mac, every textarea and text field allows emacs keys by default--do you think that's a coincidence? There are a lot of emacs users out there. And they are often some of the most technical and experience developers. Do you really want to annoy them, and drive them to another site? Also, even if there were a few, why alienate them? "Very very few people use his wheelchair ramp...let's get rid of it." :-(
    – Alex L
    Apr 29 '17 at 16:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .