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.

  • 9
    Agree. overriding ctrl bindings should never be done haphazardly. Commented Apr 22, 2011 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. Commented Dec 25, 2011 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. Commented Feb 16, 2012 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
    Commented Feb 16, 2012 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? Commented Feb 16, 2012 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
    Commented Feb 16, 2012 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. Commented Feb 16, 2012 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
    Commented Feb 19, 2012 at 9:15
  • 3
    The CTRL + H is also annoying, since muscle memory expects character deletion (instead you get the Heading shortcut).
    – Blaz
    Commented Nov 20, 2012 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
    Commented Dec 27, 2012 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. Commented Oct 27, 2017 at 9:22
  • 1
    Agreed, Emacs keys works absolutely everywhere in Unix except browsers.
    – Thomas
    Commented Oct 28, 2017 at 18:17
  • 2
    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. Commented Oct 30, 2017 at 13:02
  • Ctrl-B specifically maybe (though for me at least it's working in fewer and fewer places, for example not in the address bar), but I was referring to Emacs keys in general. E.g. Ctrl-N and many others.
    – Thomas
    Commented Oct 31, 2017 at 13:19
  • 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. Commented Oct 31, 2017 at 15:38

7 Answers 7



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".

  • I believe the underlying problem is a failure of platform localization. Apple guidelines [1] guide against changing system keyboard control shortcuts. Control-B on a Mac should be localized to command-B etc. I would also note that if this site is not a forum for discussing stackexchange common functionality, then what is? [1] developer.apple.com/design/human-interface-guidelines/inputs/…
    – Traveler
    Commented Jun 25, 2022 at 15:39
  • No, the underlying problem is a website, that has no clue about the user's environment, forcing shortcuts on that environment, breaking the user's workflow and even making itself unusable (e.g. in case of handicapped users who can't leave such website). Any keyboard shortcuts should only be set by the user's browser and never served by the website and if said website was stubborn enough to serve key bindings, it should offer an option to disable them. Period. There's no space for discussion - it's common sense.
    – cprn
    Commented Jun 10, 2023 at 19:22


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://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
    Commented Feb 23, 2012 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
    Commented Oct 5, 2012 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
    Commented Oct 8, 2012 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
    Commented Apr 1, 2013 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
    Commented Apr 1, 2013 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. Commented Jan 12, 2014 at 11:02
  • Bookmarklet does not work anymore with current so site/Firefox 27. Commented Apr 12, 2014 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
    Commented Mar 15, 2016 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. Commented Apr 19, 2017 at 9:18
  • 1
    I packaged your extension for the chrome store
    – user357287
    Commented Apr 20, 2017 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)
    – user357287
    Commented Oct 5, 2021 at 2:23
  • Unfortunately, this script has been implicated in triggering bot detection by SX. Commented Mar 16, 2022 at 20:32
  • "manifest_version": 2 is now obsolete. Boris extension has been updated to version 3
    – chqrlie
    Commented Jun 10, 2023 at 12:59

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.

  • 4
    This is why you're not supposed to use Ctrl+Alt+whatever as a keyboard shortcut.
    – Kevin
    Commented Aug 13, 2015 at 18:19
  • 6
    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
    Commented Jan 19, 2016 at 15:35
  • @cprn keyboard shortcuts are very useful.
    – user357287
    Commented Jun 10, 2023 at 15:03
  • @BorisVerkhovskiy Yes, when they're set up entirely on the client side by the user so that they wouldn't conflict with their normal workflow, not when they're served by the website that has no clue about the user's environment. The idea of websites using shortcuts is plain stupid. There's no way of telling what functionality the website is taking away from the user, e.g. the most moronic of them all - using / to jump to a website's search bar - makes every such website unusable for people using most of the voice controlled browsers because they can't leave it - they have to reboot.
    – cprn
    Commented Jun 10, 2023 at 19:12

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
    Commented Oct 13, 2013 at 10:22
  • 3
    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
    Commented Jan 30, 2015 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

Here’s an updated script.

// ==UserScript==
// @name     Stack Exchange: Kill stupid shortcuts
// @version  1
// @grant    none
// @run-at   document-start
// @match    https://*.stackexchange.com/*
// @match    https://*.superuser.com/*
// @match    https://*.stackoverflow.com/*
// @match    https://*.mathoverflow.net/*
// @match    https://*.serverfault.com/*
// @match    https://*.askubuntu.com/*
// @match    https://stackapps.com/*
// @exclude  https://chat.stackexchange.com/*
// @exclude  https://api.stackexchange.com/*
// @exclude  https://data.stackexchange.com/*
// @exclude  https://openid.stackexchange.com/*
// @exclude  https://area51.stackexchange.com/*
// @exclude  https://stackexchange.com/*
// @exclude  https://contests.stackoverflow.com/*
// @exclude  /^https?:\/\/winterbash\d{4,}\.stackexchange\.com\//
// ==/UserScript==

const ignore = ev => {
  if (!ev.target.matches('.wmd-input'))
  if (ev.ctrlKey || ev.metaKey || ev.altKey)

document.addEventListener('keydown', ignore, true);
document.addEventListener('keypress', ignore, true);
document.addEventListener('keyup', ignore, true);

Improvements relative to Rob W’s version:

  • The event handler is attached to the document node in the capturing phase, not to the textarea node itself. This ensures it will work even on editor elements not yet present on the page, allowing the script to run even before the page has finished loading (@run-at document-start) and avoiding a gap when the editor is usable with shortcuts not disabled yet.
  • The editor element is recognised by the wmd-input CSS class, not by element ID. This allows the script to work with the dynamically-inserted quick editor as well (which may be present multiple times on the page, so it doesn’t have a unique element ID), not just on the stand-alone edit page (/posts/<...>/edit).
  • Key presses without modifier keys are passed through. This is necessary because key presses are monitored for the purposes of bot detection and blocking unadorned key presses may trigger CAPTCHA prompts.

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
    Commented Apr 7, 2010 at 18:36
  • 1
    +1 for preferences setting to disable accesskeys in textboxes. Commented Apr 15, 2010 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
    Commented Apr 29, 2017 at 16:10

You must log in to answer this question.

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