Open Bug 57805 Opened 24 years ago Updated 2 months ago

front end for customizing keyboard shortcuts (configurable/user-defined keys)

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement

Tracking

()

Milestone:
Future

People

(Reporter: mikko.rantalainen, Unassigned)

References

(Depends on 3 open bugs, Blocks 5 open bugs)

Details

(4 keywords, Whiteboard: [feature] [T2] Read Comment 82 before contributing)

Attachments

(3 files)

screenshot of perfect frontend, from Textpad
14.88 KB, image/gif
Details
screenshot of alternative UI
16.15 KB, image/gif
Details
chrome files using keybindings
2.23 KB, text/plain
Details
Everybody seems to agree that shortcuts (and keyboard accelerators) are the right thing. However, everybody seems to disagree which key to use for specific action. What I'm suggesting (if possible) is to allow user to remap at least all shortcut keys and even accelerators. For example I'm used to ALT-D to change focus to address bar (equal to win32/IE5 key mapping) and I would want to use it with mozilla also (in both windows and linux!).
do you mean a way of changing the accelerator key (ie, switching from using Ctrl to Alt, or vice versa)? or, changing the keybinding itself? if the former, there's a way to do this already in your prefs.js file. if the latter, you're requesting a frontend/UI for such a feature?
Severity: normal → enhancement
Hardware: Other → All
I'm requesting frontend for keybinding. It's much easier to see a possible action and select keybinding by simply pressing keys you want to use. This should also check for conflicts between different bindings. If there is no (easy enough) way to do frontend I think including file listing of all possible actions and simple 'how to bind keys your own keys' would be enough. Changing the accelerator key should be in frontend in any case because at least in linux some users are used to meta/alt-shortcuts whereas others are used to ctrl- shortcuts. Under windows there is no reason to change accelerator key because all apps use ctrl anyway. I'm assuming that internally all actions are indentified by strings and a binding is of style "bind alt+ctrl+v file-view-source". I have no idea how key bindings are done in real life in Mozilla. It may sound like a much of work but if mozilla toolkit is to be used in another projects I think this is needed.
thanks! confirming enhancment request. cc'ing a buncha folx who might take a shine to this. ;) don/anyone, who should own this puppy?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Adding hyatt to the cc list too. I'd love to take a stab at this, if we could convince powers-that-be that it's worth spending time on. (Tell 'em Microsoft does it, e.g. in VC++ ... that'll make them take it more seriously.) In the meantime, Mira, take a look at http://www.mozilla.org/unix/customizing.html There are some notes on how to change your keybindings. Unfortunately in the current release it requires unzipping the jars, modifying the bindings there and zipping them up again, but it's supposed to get easier in future releases.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
over to akkana, nsbeta1 license-to-kill
Assignee: vishy → akkana
Keywords: nsbeta1
I just sent 18508, on the backend which would be needed before a front end would be possible, over to hyatt. I'll keep this one to cover possible front-end work and add a dependency. I'll leave the nsbeta1 keyword in place, but unless 18508 gets fixed, this one will be impossible.
Status: NEW → ASSIGNED
Depends on: 18508
Summary: feature request: option to remap keyboard shortcuts → feature request: front end for remapping keyboard shortcuts
Target Milestone: --- → Future
minus. THanks for following up on 18508.
Keywords: nsbeta1 → nsbeta1-
I just checked in a fix for 18508, and updated the customizing document to explain how to set user key bindings for text controls, editor and browser windows. (Nobody will admit to knowing how mail/news key bindings work, so they remain a mystery, alas.) That means that all we need now is a little program that can create and modify the XBL key binding format, and a way of giving that program a list of the available commands.
Un-futuring since the back-end is now in place.
Summary: feature request: front end for remapping keyboard shortcuts → feature request: front end for remapping keyboard shortcuts (user-defined keys)
Target Milestone: Future → ---
Re-futuring. This isn't something that's on aol's or my manager's agenda (in fact, it has nothing to do with my job here). That's why it's helpwanted. I took it because I think it would be a nifty hack that I'd love to help with if I have some free time, which I don't at the moment. If anyone wants to see it done soon, they should pitch in and write something. Besides, I'm practically XUL-illiterate, so it would be much more efficient if this were done by someone who's already good with XUL (or wants to become so).
Target Milestone: --- → Future
Blocks: 47199
akkana: I could do with some thoughts on how this might work. It seems to me (according to the customising doc) that we have to gather bindings from multiple places: htmlBindings.xml platformHTMLBindings.xml <other.xml> myHTMLBindings.xml Various .xul files all over the place. How would we store user bindings? Would we overwrite the original ones in the files named above, or would we need some sort of overlay mechanism? Is there some way of changing them in-memory? (There should be.) How hard is this? Gerv
No matter what solution is selected, the UI should always show the user what the *default setting* was - and have a button to reset all to defaults values. I'll file a bug for this for ALL prefs (done: bug 76648).
*** Bug 77816 has been marked as a duplicate of this bug. ***
Summary: feature request: front end for remapping keyboard shortcuts (user-defined keys) → front end for remapping keyboard shortcuts (user-defined keys)
Whiteboard: [feature]
*** Bug 93862 has been marked as a duplicate of this bug. ***
Mike T: There's no such thing as perfect frontend. If you simply want to rebind menu item accelerators I'd prefer more the way GIMP does it. Simply point menu item and press key combination you would want to use for it. The same works for any GTK application under X11, but not all applications can save those changes. Also, I think that TextPad frontend should use a tree view on the left and only one listbox. The Categories listbox changes the contents of Commands listbox (simply a guess). Selecting an item in a listbox shouldn't change anything else. By the definition of listbox, it's for selecting items, not for doing actions. This is the same thing as some some web sites using radio buttons or comboboxes with javascript for navigation - one shouldn't do it.
Mira: The GIMP method sounds intriguing, but how will users know how to do it? Wouldn't it be logical to put keyboard assignments in Edit > Prefs? Listboxes: whether the UI uses one or two doesn't matter as long as people find it easy to use. Textpad uses almost the same interface as Word for remapping keys. This is a familiar interface. If you're really set on using one listbox, Mira, you may like the Homesite screenshot below.
Attached image screenshot of alternative UI β€”
*** Bug 95533 has been marked as a duplicate of this bug. ***
It should allow binding several (two, at least) combinations for each action. That way more than one people can use one Mozilla and default combinations can still be used. When defining a key already in use, it should ask user: "Ctrl-T is already assigned to 'Open new tab'. Would you like to replace it? [YES] [NO]".
*** Bug 110521 has been marked as a duplicate of this bug. ***
Thought I'd throw in my 2 cents': I'd like to see a simple page or box listing the current bindings with buttons for <New Binding>, <Delete Binding>, <Change Binding>. For <New Binding>, dialog for <Press Mozilla key combination> then check validity then <Press New key combination> then check for conflict then add to list. An efficient way of coding the bindings I think may be some form of jump table, which is probably used in EMACS.
*** Bug 108636 has been marked as a duplicate of this bug. ***
The first step here seems to me to be getting the list of available commands, as Gerv mentioned before. Is there a way to iterate through all of the keybindings, breaking them into browser, editor, etc. like they are separated in the bindings files?
I don't know of an easy way ... but the bindings are per-widget, so bindings for the browser window are separate from editor window bindings are separate from text field bindings, etc. So it's got to be possible.
I think this bug is invalid, because it would not be an enhancement. The ability to customize keyboard shortcuts is ridiculously complicated for something as simple as a Web browser should be. If particular keyboard shortcuts in Mozilla are unnecessarily difficult to use (such as accel+L instead of access+D), file individual bugs for them.
Perhaps this wouldn't be an enhancement from a usability point of view, as you suggest mpt. On the other hand, I don't think this should be invalid. Filing bugs on individual issues probably isn't the solution since there are already cases where legitimate usability concerns go against the desires of a significant number of more advanced users (for example the bug on using PgUp and PgDown to switch between tabs). I don't think my preferences should trump the carefully considered decisions by the UI people in the community. It would still be nice to choose my own way for some things, and remapping keyboard shortcuts would be very nice for that purpose. It seems this case is similar to bug 41888 because it may impact usability therefore doesn't need to be visible to the average user or even turned on by default. I personally don't care if this is buried deeply, as long as it's there. It's not something I personally want urgently, but I reiterate that I don't think this is invalid.
I'd like to express agreement with Christopher. Although I'm not a Mozilla developer -- so I won't debate how hard this would be to implement -- as a user I consider the ability to re-map keys to my taste critical to true ease of use. A browser may be "simple," but it is used all the time, so customization matters a lot. If I were to name the one apsect of Mozilla (and other browsers) that slows down my browsing most, this might be it. Though it could be a long-term job, making as many actions as possible (re-)mappable would, I think, be appreciated by many technically proficient users. Casual users would, of course, never have to alter the (judiciously chosen) defaults.
I don't think remapping keystrokes needs to be that complicated. A "recorder" key that gets the current keystroke and gets the new keystroke. I think it will be necessary to be able to open a window of remapped key assignments. I suppose this could all be done in a pref (except the window), and the first example remap in the Help would be to remap that pref to a keystroke, ha ha.
I'd like to second Christopher and Levy. IMO a good program should offer as much control to the user as possible. Therefore shortcuts remapping while not being fundamental would be very nice.
I agree with mpt that this should be wontfixed. Fixing this bug would add a lot of complexity to Mozilla, for no net decrease in the amount of time it takes to get things done on my own computer, while increasing the amount of time it takes to get things done on public computers. There are a few things I do often that take multiple keystrokes: getting to a search engine (alt+home, alt+1), opening prefs (alt+e, e), or opening the javascript console (alt+t, t, s). But since I use those keystroke patterns often, I can use them quickly. I would not have saved time overall by trying to find unused Accel shortcuts and binding them to these actions. If I had also stared at the keyboard customization dialog and thought "What else do I do often?", I would have wasted time overall. When I use a friend's browser (or a public computer), I don't have to worry about my keys not being set, or worse, that my friend might have changed Ctrl+A to do something other than "Select All". I like it that way. The exception is that my alt+home, alt+1 for Google doesn't work on everyone's computer, because not everyone sets their homepage to http://www.cs.hmc.edu/~jruderma/s/. Following mpt's advice, I just filed bug 134614 to make Ctrl+E go to www.google.com.
Ctrl-E is taken, and changing what an existing shortcut does angers people. Furthermore, and more to the point for this bug, you may want a shortcut to get to Google, but I might not need that, because Google might be my home page, or I might use a bookmark keyword for searching Google without loading the search form at all. Instead, I might want a shortcut for toggling page colors, focusing the uabar, or some other thing you don't do very often. A good set of default shortcuts is an excellent thing, and I won't argue that Composer is a better default for Ctrl-E than Google, so I'm leaving your bug 134614 alone, but no set of defaults, however good, is an adequate substitute for customisability. I would rather have lousy defaults and be able to change them than have good defaults and be stuck with them. (Given the choice, of course, good defaults and the ability to change them is best of all worlds.) Regarding your argument about public computers: the key bindings should be left at the defaults on such systems, for reasons that ought to be obvious. Question is, how to make it easy for them to be "locked down" so that users can't fiddle. I would posit that there should be a separate rfe to allow an easy way to disable the prefs dialogs completely (and re-enable them by removing one line from prefs.js) for such situations. Then administrators of public systems (such as myself) could lock down the prefs, preventing J. Random User from changing them. If this is already extant, it should be documented more prominently. Users who don't want their own bindings to differ from those of public systems using the defaults can refrain from rebinding their keys, using the defaults. Users who don't use public systems can rebind to their hearts' content. Everybody's happy.
Another note: this doesn't necessarily need to end up in the prefs dialog, if the concern is cluttering the prefs with too many advanced things. It would be okay with me if I had to go to xulplanet and download it and install it, thereby creating a new menu item to bring it up and use it. Regarding comment 23: what Emacs uses is more complicated and involves the way lisp's fundamental data structures work. In particular, the distinction between buffer-local versus global, combined with the concept of major and minor modes, makes it different from any way it could be done in Mozilla (as Mozilla now stands), I think. But yes, it does use a series of (essentially) tables. A consequence of this is that any keystroke can be made into a prefix keystroke, or not, depending on the way things are set up. But Emacs takes key customisation to another level, that we probably don't need in Mozilla. In Emacs, any key binding calls a function, even if that function is self-insert-command. So the user or a mode can rebind what _any_ arbitrary key does. I think Mozilla only needs to allow bucky combos and function keys to be rebound, not _everything_, because unlike Emacs, Mozilla does not aim to be a lifestyle choice, with modules for everything from spreadsheets and web browsing to brewing coffee. It's mostly a web browser, with a few other add-ons for things ostensibly somehow related to web browsing. On the other hand, what Mozilla does need is for individual widgets to be able to change the bindings of certain keys when they have focus. (I think this is already done.) AFAIK Emacs doesn't do that, unless the functions associated with a major mode for a certain buffer make explicit checks for it, and that's not object oriented. (Lisp is not an object oriented language. It's list-oriented. Which is better for what it's used for, but nevermind.)
One solution for public computers: make the keyset switchable. There should always be "defaults" key profile, which could be enabled with some hard-wired hotkey or from some easy to access menu. It would be absolutely nice if I could sit on any Mozilla-enabled box in the world and type in an address that points to some private webspace I have somewhere, which would then contain my key definitions (and should probably also contain my bookmarks, other prefs, etc). If we extend this even further, it would also write new bookmarks back to that HTTP server. Well, that should go to another bug anyway (no, I don't have time to submit one). Just some ideas.
*** Bug 139517 has been marked as a duplicate of this bug. ***
I do not agree with comment #27 from Matthew Thomas that this would be too complicated for a web browser. The web browser and mail/news are the two programs I use the most. The more you use a program, the more time you can save by customizing it to fix your needs. Jesse Ruderman (comment #32) mentioned that he don't want to worry about if a friend uses different shortcuts. This is not an issue I think. After all, most users will stick with the defaults (the average user tends to use the mouse more than the keyboard), and someone changing Ctrl+A is just ignorant, right? The configurable key shortcuts feature is for changing shortcuts like Ctrl+PageUp for tab switching (see bug 136915), not for making the program useless by changing Ctrl+S or something similar. Besides, your friend can already change the shortcuts in Mozilla, by editing some xml files, so that's not an argument not to implement this *good* feature.
I agree with David Tenser that this feature is badly needed. If there is no such front-end, and you have to remap keyboard shortcuts by messing with XML, many users that would love to remap their keyboard wouldn't do that. Does anybody really believe that ordinary users don't need remapping of keyboard shortcuts? If so, consider such issues: - differences between UI conventions on different platforms: MS Windows usally use CTRL-Tab for navigating between window's frames while in Linux (Gnome) it's used to switch between widgets (buttons, text fields etc), Mac doesn't have the F1-F12 keys, etc, etc... - left-handed users vs right-handed users (e.g bug 136915 discusses switching from CTRL-PGUP, CTRL-PGDN to CTRL-TAB, CTRL-SHIFT-TAB for tab switching. That would be a catastrophe for me, because those key combinations are so much harder for me with a right hand) - internationalized Mozilla versions which might have slightly varying shortcuts - internationalized versions of operating systems and different keyboard layouts (there was a time when keyborad shortcuts in Mozilla conflicted with the ability to input Polish diacritical characters because with Polish programmers keyboard layout you type them using ALT-LETTER combination. Can you guarantee that no single key combination will conflict with any given keyborard layout for any given language?) All those issues can't be addressed only by careful design by Mozilla UI team. There are things you just cannot predict. And I didn't yet mention that people tend to have personal preferences with regard to keyboard shortcuts... And those preferences sometimes conflict, which can be seen in Bugzilla in the form of bugs like bug 136915, bug 108636, bug 134614. Without a frontend for easy remapping of shortcuts, those bugs will just keep coming and haunting us wasting our energy that could be utilized for something more important than arguing whether CTRL-E is a good binding for Edit Page (btw I really _do_ use it more often than a web search, Jesse. You don't have the power to see what all, or even most users, look like).
*** Bug 150444 has been marked as a duplicate of this bug. ***
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Your url is broken!
famtie: it's a netscape internal document. I don't know if there's a gecko2 spec outside the firewall; I'll ask, but I suspect this is more a planning document for Netscape resources. I'm having a bit of a problem understanding how an RFE for a XUL front-end can be listed as a topembed bug, though. Any gecko2 people want to clarify? In case anyone is wondering about status, this bug is still looking for an owner who's good at XUL UI coding. I'm very happy to help with the back-end (including writing new accessors if needed) and getting it all reviewed and checked in if someone wants to step up and take a crack at the UI.
Turns out the document in question says (I'm sure I'm not revealing any secret information here): "Produce and document API for changing default key bindings" and a reference to this bug. So there's a confusion between an XBL key binding API (I assume they're not interested in XUL key bindings) and the that this bug discusses. There should probably be a new bug filed for the embedding issue of an XBL key binding API, with some indication of what level of functionality embeddors expect to see. I'll talk to Marek about that.
Changing from topembed, to embed, as this is not currently blocking a major embedding customer.
Keywords: topembed → embed
Blocks: grouper
Bulk adding topembed keyword. Gecko/embedding needed.
Keywords: topembed
Keywords: access
Not really an embed issue at this time (edt)
Keywords: access, topembed → topembed-
Whiteboard: [feature] → [feature] [T2]
Assign to nobody to make it clear that this will require a XUL person. (Still don't understand why a XUL front-end bug is on the embedding feature list, but my mail messages asking about that have gone unanswered.)
Assignee: akkana → nobody
Status: ASSIGNED → NEW
Is there a documentation on how the backend works and can be used from JS?
johann: see comment 4.
*** Bug 172130 has been marked as a duplicate of this bug. ***
This depends on being able to add and remove XBL key bindings once moz is already running. Adding some dependencies which relate to those issues.
Depends on: 51261, 51262, 74416, 89524, 119078, 163023
*** Bug 183400 has been marked as a duplicate of this bug. ***
I believe that customisable keyboard shortcuts are very important, and the process of unzipping/modifying/rezipping files is somewhat beyond most users. Personally, the shortcut which gives me most problems is Ctrl-Q. In most of my other applications, this will close the current window if the application has multiple windows (such as a browser). I hate the fact that the same key in Mozilla closes all windows - browser, mail etc. It's not easy to mentally switch between Ctrl-Q and Ctrl-W depending on which app happens to be running.
*** Bug 196098 has been marked as a duplicate of this bug. ***
Blocks: 129472
*** Bug 203808 has been marked as a duplicate of this bug. ***
From comment #21: When defining a key already in use, it should ask user: "Ctrl-T is already assigned to 'Open new tab'. Would you like to replace it? [YES] [NO]". Oh god, please no! Pop-ups SUCK! One of Mozilla's most wonderful features is its ability to limit these damn things.
The popup should only be showed when you are defining a new key combination. How else are you going go get a yes/no responce from the user except for a pop-up window with a question?
The way word and OpenOffice do it is quite nice. In their keyboard customization dialogs you select the function to which you want to bind a key (from a list, by typing the name of it on the keyboard if you wish), then you hit Tab once and it takes you to the text box in which you can enter a shortcut. Once you have entered one, a text label beneath that text box is updated to display the message "currently assigned to: functionXYZ". If the shortcut is not in use, it says "currently assigned to: [unassigned]". Also as a response to the user entering a shortcut, an "_Assign" button becomes enabled, allowing the user to next type Alt+A to assign the entered keybinding to the selected function. After making the assignment, it moves focus back to the list of functions so that you can type in the name of the next function that interests you. You can enter keybinding after keybinding without having to deal with pop-ups, function keys, arrow keys, or the mouse! As much as I dislike M$, and especially most of the dialogs they've ever created, this dialog is very slick, and a wonderful UI.
I agree that popups are the very last thing we want. I also agree with comment 58. A more systemized UI would negate any confusion over duplicating a key combination.
from Comment #25 - Dean Tessman: The first step here seems to me to be getting the list of available commands, as Gerv mentioned before. This in my experience is the hardest part. Unfortunately, I have never spent time actually trying to learn the Mozilla codebase, and flopping around doing one little thing at a time doesn't seem to have afforded me much insight into what's going on. Maybe that's why, or maybe it's just really darn hard to find these things. For someone like me, an adequate solution to this problem would be just to have someone in the know go through and create an actual list of _all_ the key-bindable functions, and what files to edit to change/add them. Also useful would be a HOWTO on how these key-bindable functions are created in the first place. (XUL? C++? where for different kinds?) That said, this solution will probably not be useful to the masses. But with all the nifty development tools in Mozilla, I'd think it'd be one more feature to win that whole community. Hey, more potential contributers.
from comment #34 - Jonadab the Unsightly One (Nathan Eady): I think Mozilla only needs to allow bucky combos and function keys to be rebound, not _everything_, because unlike Emacs, Mozilla does not aim to be a lifestyle choice, with modules for everything from spreadsheets and web browsing to brewing coffee. I strongly disagree with the few comments posters have made along the lines of this one. Aside from my shell and editor, I spend more time in this application than any other. And it is the only choice for web browsing that I believe I have (Linux). And as someone else already said, I might do function X 200 times a day, where most people rarely use it. So there will be no cmd_X, and I'll have to go through three levels of submenus every time I do it (I actually had this experience in VisualAge for Java). Also, regarding the debate of good defaults vs. customizability, there are _many_ reasons for various people to choose shortcuts that suit them. Left-handed mouse users may want to ensure that some of the functions normally mapped to the left side of the keyboard be available on the right side. Some might want to make the shortcuts adhere to those they learned in another browser. I personally can't tolerate any shortcuts for functions I use often that require me to move my hands from the home keys position (i.e., no arrows, no page up, page down, etc.). Another reason I have for some of my choices is that I tailor almost all the apps I use regularly to use basically the same key strokes for similar functionality, like search, page up/down, line up/down, etc. I suppose I'm rambling, but my main point is that you simply cannot predict what is most important to each user. And discounting it is not a good idea, either.
nobody@netscape.com is about to go on a long vacation to the bit bucket
Assignee: nobody → nobody
.
No longer blocks: 129472
Are you saying that you're going to flush this bug? Why not just leave it? You can't possibly disagree that keyboard shortcuts in Mozilla are fubar. Even if there is no one that can handle this right now, I can't believe it's so unimportant to merit dumping it altogether. This is integral to the UI! You absolutely cannot use Mozilla without a mouse right now, let alone use it comfortably. In my utopia, it would be considered completely broken for this flaw, and I'll wager most anyone who has learned and loved vi (or Emacs?) would agree with me.
Richard, you might want to look at the status (my bugzilla is still showing it as open -- is yours different?) and what it says next to the Assigned To field. Meanwhile, this has become academic because key bindings have regressed; it's no longer possible to make new XBL custom key bindings even by editing files by hand. :-( Adding a new dependency on bug 201011.
Depends on: 201011
Akkana, I am referring to comment 62, which states: nobody@netscape.com is about to go on a long vacation to the bit bucket nobody@netscape.com is a fake user has been assigned to handle this bug, and I think that "bit bucket" means the trash, so I take this post to mean that they are about to throw this issue (along with any others assigned to nobody@netscape.com) in the trash. - richard
no, the *user* "nobody@netscape.com" got thrown in the trash. That's why all of "his" bugs got reassigned to "nobody@mozilla.org" which still exists.
At the time that announcement was made, this bug was *changed from* "nobody@netscape.com" to "nobody@mozilla.org". It was changed so that it would continue to be assigned to an account that was valid. (As you say, the Netscape account is being discontinued.) So, the reverse of what you claim is what actually happened. Changing the assignment was so that the bug would stay alive, not so that it would "die". Hence Akkana's comment to look at the Assigned To field (and to notice that it's not assigned to "nobody@netscape.com".
[That may be true, but I still think this is actually part of an evil anti-keyboard-shortcut conspiracy among mozilla.org, the military-industrial complex, and the dictatorship of the proletariat. Someday, all will be revealed!]
Web interfaces (and along with them Web Browsers) are increasingly being used for data entry systems. One particular "keybinding" is of great relevence, the backspace = back which in Mozilla is active on the windows platform but doesn't seem to exist in the Linux version... I can't find any way to diable it. Obviously this "keybinding" is inactive when the focus is on a text entry type of element, but fat fingers are everywhere. It seems like someone put it there so Mozilla would act like IE on its own platform. The problem is there is a work around you can put in an individual web page to disable the key in IE for that page, but it doesn't work for Mozilla. It is imperitive to the future of Mozilla as a data entry front-end that there be a way to disable the BACKSPACE = Back "feature".
It's no problem to disable backspace on the webpage itself. Use an onkepyress handler. If the key is backspace, do event.preventDefault()
Today I set out to assign a shortcut key (or keyboard binding) to the rewrap function in Mail. I use Netscape 7.1. From pine I was used to use ctrl-j to rewrap long lines somewhat intelligently and rewrap in Mail provides the same functionality. It is only really useful when available in a shortcut since it is a editing command used while typing and formatting. My first assumption that there may be prefs for each keyboard binding. Wrong. After some googling I found on mozilla.org a page which explains. Now, I cannot find the link. The page mentions htmlBindings.xml platformHTMLBindings.xml in res/builtin and shows a way to add custom shortcuts in a separate file whose name must then be registered somewhere else. One also has to find which element or widget it is to which the command is applied. DOM inspector came to the rescue and showed the mail compose window has an "editor" element. The shortcut keys for the editor element are assigned in the editor section in platformHTMLBindings.xml. DOM inspector also showed the function name to be assigned to the keyboad shortcut for rewrapping is "cmd_rewrap". I had found out by searching the source code on mozilla.org before and this was good live confirmation. I decided to edit platformHTMLBindings.xml directly and just added this line <handler event="keypress" key="j" modifiers="control" command="cmd_rewrap"/> to the editor section in the file. After restarting, it worked somewhat to my surprise. In Mail I can now rewrap by typing ctrl-j(ustify). Of course, there should be a much easier way to customize shortcuts. Andreas
Blocks: 219203
*** Bug 223005 has been marked as a duplicate of this bug. ***
I believe a menu to reassign keys it's a basic feature that mozilla should have. Take a look at any KDE application and their "Change keyboard shortcuts". It's the most intuitive way: a list of actions, and you can assign 2 keys to each action. This way you can maintain the original keybindings and add your personal keys. The same front-end prevents you from setting the same shortcut to 2 actions, saying "You can't set CTRL+BLAH to "Compose New Message" as CTRL+BLAH is currently assigned to "Compact Folder". I've been waiting for a keyboard-shortcut-changing fronted in mozilla for about 1.5 years... Thanks a lot anyway por the browser itself :)
Blocks: majorbugs
The default shortcut keys have become so good that I personally no longer see any use for the ability to customize. Customization would only bring unconsistency. Removed my vote for this bug.
I disagree. It is matter of offering the user a choice. Some people will always be familiar with some settings. At least the ones who made them. This should be done - see for example comment #74.
I strongly disagree with Comment #75. I'm sitting here with a major spasm in my right arm between my wrist and my elbow after hours of mousing around the menus in Composer to perform repetitive functions that could be done in a fraction of the time and with a fraction of the physical wear & tear if I could just assign keystroke commands to those functions. I could understand objections to fixing this bug if it constituted a limitation on or removal of existing options, such that it would somehow negatively impact users. But this is not a matter of imposing any such interference with users. Those who don't need the feature simply don't have to use it. I don't deny any user his right to allocate his votes as he sees fit, but let's not confuse that right with the larger objective of making Mozilla more useful. There is nothing about fixing this bug that would reduce Mozilla's usefulness to any user, but there is a great deal about fixing it that would increase Mozilla's usefulness to me, and I suspect to many other users.
I totally disagree with comment #75. Everybody is free to retire voting from a given bug at any moment, but trying to convince others that making Mozilla a better browser could "bring inconsistency" is quite selfish. Trying to REPLACE the mozilla default keys would be bad, but adding the chance to change all according to user's needs can be never bad. See you.
There's also the matter of adding shortcut keys for functions that don't have any by default. Being able to add shortcut keys for the site navigation toolbar functions could be handy.
This is about giving the user the freedom to make the system work the way they want it to - strange to hear anyone argue against this in an OSS setting. Opera has it: file / preferences / mouse and keyboard. Start typing description of the function you want to assign and you get a picklist of matches (so you don’t even need to know function names). You can even assign to a mouse gesture if you like, and the function can even be a URL call. Three real-life examples of why central planning is not good enough: 1. re-assigning keystrokes: Googlebar replaces a built-in feature (basic toolbar search field) and renders it obsolete - yet the hotkey Ctrl+K remains assigned to the removed function, and can't be used for anything else (by a non-coding user). 2. re-assigning functions: Googlebar's default hotkey, Ctrl+F12, is a two-touch, two-hand gesture requiring shift of visual focus to the keyboard and rotation from the elbow: pretty crude. I spent several hours trying to reassign it by editing GooglebarOverlay.xul, without success. Strokes I tried were F4, Ctrl+G, Ctrl+K, and tap on Shift. Problem for most is that they’re assigned elsewhere in Firebird, and those bindings pre-empt what you specify in the XUL file. Trying to stop a second tap on F4 from dropping down the history list, I tracked down and commented out two other bindings (menulist.xml and autocomplete.xml), but VK_F4 also occurs inside Firebird.exe, which was more than I could deal with. 3. accessing html documents (web or local): I made a sidebar help chart for customized mouse gestures, but as far as I know I can only get at it by pointing and clicking a link. In Opera I could assign the URL to a mouse gesture. With Firebird, I can’t make these simple refinements without becoming a hacker. With Opera, I’d be done in a minute. If the objective is to provide the best browser in the world, customization fluency is one of the things which has to be world-class.
I'm just going to toss another reason into the fray: 5. There is still an on-going <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=186789">bug 186789</a> that prevents ctrl-shift sequences from working in a GTK2 setting. While Windows users may be all too happy to keep their ctrl-shift sequences (such as ctrl-shift-c for marking all messages read), linux users using GTK2 can't use such as the bug has not been fixed. I'm not all that happy to have to continually search for the "Mark all read" setting in the menu-bar all the time when I could much more easily set a new keyboard shortcut to work around the "feature." Thus, allowing user definition of alternate keyboard shortcuts would at least allow some leeway until 186789 gets resolved.
Please stop. We know that this is a wanted feature. Nobody ever said it wasn't. That's why this bug is still open. Unless you have something to contribute to how to resolve this RFE, it's already been said. Patches are more than welcome. The UI isn't the big issue here, the big hurdles are things like mentioned in comment 25 and comment 26.
Whiteboard: [feature] [T2] → [feature] [T2] Read Comment 82 before contributing
"nobody ever said it wasn't" - see 27, 32, and 75: all arguing that remappability is either unneeded or bad, and that the RFE should be killed; and 34, arguing that limited remappability is enough. The issue appears to be open.
This bug is not for arguing (especially with the ghost of mpt ;-) over the feature requested in the summary. If the affected module owner, or someone with higher authority, said "no way, we don't want this fixed" and WONTFIXed the bug, it *still* would not be the place to argue with that decision. But since there has been no such decision, and since Dean and others, including me, are in favor of this bug being fixed, please stop spamming it with advocacy arguments. The way to go here is to find someone who can fix this bug and persuade him or her to take assignment of it. /be
> The UI isn't the big issue here, the big hurdles are > things like mentioned in comment 25 and comment 26. While that is true, if someone stepped up to write the UI portion, they could start with something that looked at the key binding files and wrote out to those files (requiring a restart before the new key bindings take effect). That would get many users most of the way there (as long as they have write permission on the key binding files, which is a requirement anyway until/unless the userBindings.xml bug 201011 is fixed); and if there was a UI volunteer it would increase motivation for backend people to figure out how to expose things like existing key bindings.
I've looked into this a little - my big thanks to anyone who gathered almost all keybindings from UI XUL files (if I remember it well :) to the toolkit XMLs (probably only inspector and messenger modifies some of them for their specific usage). If anyone is interested (or just wants to start somewhere) here is the list of chrome files which use keybindings. I've searched for phrase 'event="key', but it's some time I've last played with XU/BL so I wouldn't be surprised if I missed something. (res/builtin/htmlBindings.xml and res/builtin/platformHTMLBindings.xml not included; don't forget userBindings.xml) Some thoughts: A lot of these bindings are almost as pretty as they could be in this world - the key is defined as 'keycode' attribute on <handler>. But a lot of them are nasty - the key is distinguished in JavaScript code inside appropriate <handler>. This has to be analyzed to get things sorted. I don't like the idea of rewriting chrome files but that depends on someone actually implementing this bug (don't expect me learning C). Either way - please store somewhere original bindings before rewriting them with the new ones ^_^
Hrm... I knew it. Everytime you finishe something there's a lot more you didn't see before. So I'm taking my words back - if I understand it correctly it's as messy as ever before. I've got confused by the fact that some keybindings in searched files actually do something in browser etc. All relevant bindings (read "what most people would change") are defined in DTD files. Because it should be customizable by translators. So... *deep breath* We need some "overlay" mechanism for XBL bindings, for DTD files, for XUL files... Anybody still wondering Mozilla has no customizable keybindings? I'm not a programmer but with so big diffuseness of things we need to keep track of I don't believe it's possible to figure out how to get all this together. Am I missing something? ^_^" Toolkit bindings need own mapping (and one must dig into the code to actually find out what it is supposed to do), XUL bindings are partly defined in DTD (under rather descriptive names) and partly inside XUL files themselves. If we want to expose bindings to the user we would evidently need to keep separate list of descriptions for bindings and their mapping to approprite files and every change in chrome should have been reflected in this list... No, it can't work. If there was a plan for customizing keybindings I don't see it. If I should have to create customizable layer over this I would mark elements in XML itself as customizable, by some link-like attribute, and would keep track of user changes to the default behaviour. User bindings having precedency. Sounds like adding another layer between keyboard and XUL... Tell me there was a plan some years ago... Sorry for the spam. I hope more then three year old bug with 54 votes deserves some "catharsis"...
*** Bug 233351 has been marked as a duplicate of this bug. ***
*** Bug 240316 has been marked as a duplicate of this bug. ***
*** Bug 234963 has been marked as a duplicate of this bug. ***
Summary: front end for remapping keyboard shortcuts (user-defined keys) → front end for customizing keyboard shortcuts (user-defined keys)
The keyconfig extension offers this functionality for Firefox. It's a little rough, but it's a start.
(In reply to comment #91) > The keyconfig extension offers this functionality for Firefox. It's a little > rough, but it's a start. Thanks, Dean. I'll check it out. You're right, of course...anything is better than nothing. Too bad it has shown up in Firefox, where there is a complete separation from the editor function -- either in Composer or in the mail composer. In fact, that's what has driven my request for this feature from the get-go. But I won't belabor the point; all the arguments in favor of this bug have already been made. Again, thanks for the heads up.
Summary: front end for customizing keyboard shortcuts (user-defined keys) → front end for customizing keyboard shortcuts (configurable/user-defined keys)
FYI: http://www.mozilla.org/unix/customizing.html does not work. Is there a new method to customize, for example, the navigation keys in a textbox? If you create a new xbl binding that extends from the default textbox and add a keypress handler for a key that is already bound for the textbox, shouldn't it be overridden? ... <binding id="binding1" extends="chrome://global/bindings/textbox.xml#textbox"> <handlers> <handler event="keypress" key="y" modifiers="control" command="cmd_paste"/> </handlers> </binding> ... But alas, it doesn't.
*ahem*. my bad. the above URL does work to customize bindings. I'll crawl back in my hole now.
I am excited that this is being discussed. I would love to be able to reassign control-o to open a new page and control-n to open a new tab.
*** Bug 248895 has been marked as a duplicate of this bug. ***
*** Bug 251871 has been marked as a duplicate of this bug. ***
For me, the greatest obstacle to adopting Thunderbird & Firefox as opposed to sticking with Mozilla is the lack of consistent keyboard shortcuts. My fingers "know" that Ctrl-N opens a new browser window, and Ctrl-2 opens the E-mail window (in Mozilla). If /only/ they would do the same thing in Thunderbird and Firefox respectively ... Philip Taylor
Hello ... I'm using mozilla products for a couple of years (firefox and thunderbird did not exist then :), and I'm waiting since then a way to change the keyboard shortcuts easily, like all the KDE applications can do. What's the status of this bug? It is planned to add a keyboard-remapping UI window? Thanks a lot :)
I'm using Fedora Core 3 with KDE 3.4 and Firefox 1.0.2 on a laptop. I'm not sure exactly which bit of software is at fault but when I least expect it, the click and drag effect that can be used with the touch pad on my laptop, sends a forward or back signal to firefox. I'm assuming its a KDE thing that sends Alt + Left/Right so I was hoping that by changing the key assignement I could stop it jumping back when I'm trying to scroll down a page.
Re comment #100: are you sure you haven't installed any sort of "mouse gestures" package, either in firefox or in kde? Getting rid of the gesture handling might be a better solution than disabling those mozilla keys.
No longer blocks: majorbugs
*** Bug 321497 has been marked as a duplicate of this bug. ***
Can I add mine to this -- lack of consistent and comprehensive key mapping and menu editing is important for user efficiency. Ability to take the pool of "known commands which have keys mapped to them" and then move them to different menus or add different key combo's for them, and icons. Microsoft has it (office 2k). Its time Mozilla did, I think.
*** Bug 347907 has been marked as a duplicate of this bug. ***
Is this scheduled yet? I would love to easily customize keyboard shortcuts of thunderbird because im using "the bat!" on windows and would like to use same shortcuts like there...
@Dean: Is there and documentation for keyconfig extension that a normal human can read? For simple things like scrolling messages in Thunderbird I cannot find any information at all. I'm actually of the opinion that an extension _is_ the proper way to handle this issue. The bug requests a feature that few users will ever need, however, it is essential to those who need it. That said, I am voting for the bug as it's implementation will make my life quite a bit easier. I have a broken right hand, and as it stands, I cannot use applications that force me to use either the mouse or shortcuts that require two hands.
Dotan, the only documentation I've found is in the MZ thread: http://forums.mozillazine.org/viewtopic.php?t=72994 I've never tried it, but the Functions for KeyConfig add-on looks like it can give you the scrolling control that you need. http://www.pqrs.org/tekezo/firefox/extensions/functions_for_keyconfig/
Thanks, Dean. That is a long thread, but I'm getting there. I do know about Functions for keyconfig and I use it. Thanks.
Dorando has keyconfig extension Ctrl+Shift+F12 available at http://mozilla.dorando.at/ should be built-in to Firefox, but would not want to lose any features that the extension has, and just because multiple actions have same keyboard shortcut does not always mean a conflict. Allows sorting on Name and sorting on Shortcut. Buttons for adding a new key, Apply, Disable, Reset. Conflicting assignments are highlighted on the Shortcut. I've used it for years and it works great had a lot of problems because couldn't update my shortcut changes when Version 3 came out during testing, which a good reason that it should be built-in. Allows you to change any existing keyboard shortcut to another shortcut, or remove a shortcut. [options][tools] Using default Ctrl+Shift+F12 Not nice to have to change keyboard assignments but was very necessary, the extension is very useful in identifying keyboard shortcut conflicts by sorting on key. Dorando is alive and replies to questions in the forum, and did update for version 3. Documentation exists at: More than was supplied in #91, #92, #110 -- http://forums.mozillazine.org/viewtopic.php?t=72994 http://mozilla.dorando.at/keyconfig/examples.html http://forum.addonsmirror.net/index.php?showtopic=254
QA Contact: bugzilla → keyboard.navigation
Is there a schedule for this bug? It's great to have an extension to do change keyboard shortcuts, but the settings dialog is more intuitive. The use of web browsers is changing. Years ago they were used mainly for navigating through web pages. In the last few years, text processing got more and more into the browsers, be it in web mail applications, forums or even online office applications. The direction goes to more fields such as image processing, music editing or whatever offered online in the browser. There is no possible set of keyboard shortcuts that fits for all these kinds of use. The often-cited backspace behaviour is great for navigating through websites, but most annoying for text-processing purposes. The average office user will expect keyboard shortcuts in Firefox to behave as in his/her favorite word processor. A musician might be used to shortcuts of Logic or whatever, a graphic designer to the ones in Adobe products. They all will be most annoyed, if they work in an online application, hit their favorite shortcut, and the browser does something unexpected which might even cause loss of their data. Additionnally, an import/export function for keyboard shortcut sets would be great for people who work on a lot of different computers, such as freelancers, combined with a "change shortcut set for this session only" option...
Blocks: 542573
This feature request exists for as long as Firefox exists... actually even longer than that. Watch the dates when some of the (now) "duplicate" bugs have been filed. The main problem is not Fx itself; the developers make sure there are more or less good keyboard shortcuts, usable on every platform (and sticking to platform conventions if possible and those are existing), the problem is that pretty much every second add-on adds new keyboard bindings and I have at least three add-ons, that all three want to use the same keyboard shortcut. There are simply not enough keys on my keyboard to give every one an own shortcut and add-on developers don't make sure their shortcuts don't conflict with other existing add-ons using shortcuts (considering the number of add-ons, that would be pretty much impossible). Further many add-on developers use only one platform themselves and choose shortcut that are pretty awkward if not impossible on other platforms. This leaves three ugly workarounds for most people: 1. Change bindings by "hacking" around in source or config files. 2. Use an ugly, unreliable extension named keyconfig, that sometimes is willing to work with whatever Fx version you are currently running and sometimes won't get updated for months. 3. Bother the add-on developer long enough, so s/he makes the shortcuts configurable in the add-on prefs, which means partially the same code over and over again, but each time a completely different UI and new bugs and problems. This is just ridicules, as even tiny freeware apps will often allow you to customize your keyboard shortcuts, aside from pretty much every bigger software package (e.g. LibreOffice of course allows you to customize shortucts). And if there exists an extension that can do it, then Fx should be able to do it as well. Further if there was an official way (API) how add-on developers should register their shortcuts, so that they are customizable and not cause conflicts, I'm pretty sure *ALL* add-ons developers would be more than happy to exclusively use this API. So if it was necessary to rewrite the shortcut handling of Fx and make all people migrate to a new API to make this feature work, this will be the smallest problem. My expectation is that there is a place in the preferences for customizing the keyboard shortcuts, that lists all existing shortcuts of Fx itself and further all shortcuts registered by add-ons. There should be a "Function Name" per shortcut, a "Short Description", the shortcut itself (might be empty, if unassigned) and all this should be sorted in such a way, that it is clear where the shortcut comes from (if it is from an add-on, it should be clear which add-on, if it is core part of Fx, this should also be clear). This function is missing since the first add-on developer decided that a shortcut for his/her add-on is a good idea.
Please see comments 82 and 84. This isn't just a Firefox issue. This bug was filed for the Mozilla Suite--long before Firefox existed--and it still affects SeaMonkey as well. If you've voted for the RFE, that's terrific, but what's really needed is a solution. As you can see if you read the entire thread, it's not a simple matter...but I'm sure everyone will join me in encouraging you to have at it. Good luck!
@freevito: This bug won't fix on its own and nobody is actively working on it at all for YEARS now. Just FYI, I said Firefox, because my original bug, which was about Fx, has been closed as a duplicate to this bug some day (within the last TEN years where this has been a major unresolved feature request across all Mozilla products). This bug is blocking on issues, that haven't been touched for 3 to 5 years, if they even exist at all as of today. This bug is talking about internal structure that certainly is not the same as it was 5 years ago. "You cannot be better without being different", who said that? Well, doesn't matter, but the last time I heard this sentence, it was from the mouth of a Mozilla developer. So let's be different then! Lets stop using the crappy XUL ways of how keyboard shortcuts have been done the last 10 years and lets solve the issue *at its root*. They way how this system was designed is flawed, broken by design, and there is no way to fix it. If you cannot fix it, drop it! That is, replace it with a different system that works. Don't waste time on hacking nifty, but ugly workarounds for a problem that wouldn't even exist if you'd just do it RIGHT(tm). Do you know Komodo Edit or the Komodo development suite? It is based on XUL. Give it a try, the editor is free: http://www.activestate.com/komodo-edit Even though it is based on XUL, all keyboard shortcuts, be it shortcuts of the editor or of the menu or of some plugin, they are all customizable (some only take effect after a restart of the application, but they are customizable; they even show correctly in the menu after a restart). So why can they do it and other XUL apps cannot? If some major redesign of all keyboard handling code, a new central API or dispatcher, is necessary in the XUL framework, so be it. Then lets start planing and discussing one, then implementing it and finally merge it into the existing code base, so we can start moving all keyboard handling to it. However, this won't happen if we sit here, twiddle our thumbs and wait another ten years for this bug to magically fix on its own. Since 2005, about once every 6 month or so some other bug was resolved by making it a duplicate of this one or one or two more or less useful comments have been posted and other than that, there was exactly *ZERO* progress on this issue. So how many more years have to pass, before only a tiny step is made by anyone towards resolving this bug? Comment 82 was **SEVEN** years ago and what has been suggested in comments 25 and 26 has not happened as of today and is actually a complete waste of time, since it is not necessary to solve this issue at all. Feel free to keep pointing to comment 82 another decade, but I'm looking for someone who really seriously wants to work on this issue, instead of living 7 years in the past (no offense intended). And for whomever this is too much noise on a 10 year old bug, unsubscribing of this bug is just one click away.
@TGOS I don't take any offense whatsoever. I'm sorry that the meaning of my post wasn't clear. I'll try to state it more simply. I'm sympathetic toward your frustration with the still-unresolved status of this bug; after all, I voted for it too. I agree completely that the bug will not resolve itself. But neither will venting about it. (No offense intended.) In fact, I appreciate your passion, and I hope that you will turn it to productive use. The assignment status at the head of this page says "Assigned To: Nobody; OK to take it and work on it". Evidently, for the past 10 years, Bug 57805 has been waiting for you to come along and take ownership. I'm sure the other folks who voted for it will appreciate your successful efforts.
Before I change to FF4 I'd like to know whether this feature request is solved in FF4 or whether keyconfig still works under FF4 when compatibility is adjusted. Can anybody tell? Thanks
Bege, a quick check and I don't see the ability to customize the key bindings in Firefox 4.0 with the Keyconfig extension. In a rush otherwise would look further in to it for you.
Everybody: It is possible to edit keybindings in FF4: Quelitu people (<a href="http://wavesofthefuture.net/computers/linux-operating-system-refurbish-computer-free.shtml">an operating system for upgrading/recycling old computer... and for new ones too</a>) have a solution to configuring keyboard keys. Go to this page and scroll down to: <a href="http://wavesofthefuture.net/computers/quelitu-lubuntu-guide-increase-speed-windows-computer.shtml">ο»ΏEdit Firefox 4 (FF4) Keybindings / Keyboard Shortcuts / Keyconfig Alternative</a> Let me know if this helps.
I just filed bug 673669 for one narrow part of this wider issue.
Is there a simple way to solve https://bugzilla.mozilla.org/show_bug.cgi?id=701042#c14 ?
Blocks: 411198
Blocks: 851504
What's the status of this issue? With the advent of WebExtensions, there is no longer an extension that will provide this functionality.
Blocks: 1215061
18 years... This used to be able to be fixed with addons but since the new API is not good enough, we lost this ability. Any chances we can get this features between now and the next 18 years?
At least for some keys, you can still change (at least some) key bindings in quantum by modifying omni.ja. I documented some steps: http://shallowsky.com/blog/tech/web/modifying-omni.ja.html
Gentle reminder that comments are not for berating one another. The WebExtensions team is aware of what's being asked for and that work is being tracked in bug 1215061.
It would be useful to also include the customization of mouse keybindings (e.g. double click, wheel scroll etc.). I hope this feature gets implemented before XBL is removed. At least for now we have UserChrome+XBL and still "there.is.only.xul" helping us power users workaround the questionable decisions of Mozilla in recent years. Hopefully when "there.is.no.xul.et.al" something at least equaly customizable will replace these technologies and the user customizable bindings are a necessary part of such replacement. Well, false hopes are better than no hopes I guess.

(In reply to Bakhelit from comment #135)

… mouse … (e.g. double click, wheel scroll etc.). …

Will about:shortcuts be suitable? Bug 588710

(In reply to Graham Perrin from comment #136)

(In reply to Bakhelit from comment #135)
...
Will about:shortcuts be suitable? Bug 588710
...

If about:shortcuts gets implemented similarly as described in bug 588710 it could really be the end of all shortcuts related issues. I would personally welcome that feature very much and I guess many other users would too:).

Component: Keyboard: Navigation → User events and focus handling
See Also: → 1608766
See Also: → 615957
See Also: → 511741

On macOS, the Keyboard System Preference pane allows setting shortcuts on a per application basis. Thunderbird sort of pays attention to that, in that if I set up a shortcut, that shortcut appears in the menu and invoking the shortcut performs that action, but it doesn't remove the original shortcut from working, so I can't use it, for example, to get rid of the extremely annoying use of A as Archive. Thunderbird should use whatever shortcut has been set in the Keyboard preferences pane only for invoking an action (if one has been set, falling back to the default if nothing set obviously.)

Windows PowerToys has a similar per application shortcut system. I suspect Thunderbird knows nothing about this at all.

Hi Brian and Marc,

Thunderbird is a totally different product than Firefox even if it's build on top of Firefox source code. To make sure your feature request is taking into consideration by the Thunderbird team, I'd invite you to open a new bug.

Yeah, sorry Danny, I got here via a link in a Thunderbird bug, and didn't read this bug's details closely enough. However, I will note that the exact same issue exists in Firefox (95.0.2 on macOS Mojave). I can set a keyboard shortcut in the Keyboard preferences pane and the shortcut will show up in the menu and work, but the old shortcut will also work. It's not as big of a deal in Firefox as Firefox doesn't have a whole slew of single unmodified key shortcuts like Thunderbird, although I do occasionally accidentally quit Firefox when reaching for command-W. In other applications (including Chrome) I've redefined Quit using the Keyboard preferences pane to have a harder to accidentally type shortcut, which I can't do in Firefox.

To share a use case that is similar to Brian, I use Cmd-Alt-H / Cmd-Alt-L in all my apps to switch tabs/threads/etc, unfortunately the former is mapped to "Hide Others" in Macos by default for all the apps (a feature many people don't care about).

The usual workaround is to add a (bogus / complicated) keyboard shortcut in the Macos System Prefs for "Hide Others", which frees up the default shortcut. Problem is, Firefox doesn't still thinks the shortcut is a "Firefox shortcut" when trying to assign it in the Extension preferences.

This workaround is not even necessary normally because most applications allow switching tabs ("Show Previous Tab" / "Show Next Tab") from the "Window" Menu, in which case one can simply assign the shortcut in the System Preferences without any Extensions.

This issue should not focus exclusively on Macos users, but it is worth noting that adding more common commands to the Menu is a nice way to sidestep the problem for these users.

Severity: normal → S3
Duplicate of this bug: 257241

The following field has been copied from a duplicate bug:

Field Value Source
Keywords access bug 257241

For more information, please visit auto_nag documentation.

Keywords: access

y'all broke the Okta shortcut 3 years ago with https://bugzilla.mozilla.org/show_bug.cgi?id=1328637 when you took over command/control-shift-o from Okta. Given that this makes it nigh impossible to use muscle memory and shift back-and-forth between Chrome and Firefox you are hurting your own adoption and usage. Please address this multi-decade old bug by providing some ability to remap the built-in shortcut keys.

Open 24 years ago?? Wow. That has to be a record. It would be nice to have this issue fixed before it gets married and starts having babies πŸ˜†

This is such an essential accessibility feature on every app. Opera, Vivaldi and Brave all allow this sort of customization without requiring any 3rd-party extension. An extension is not really a solution, because you can't customize it everywhere, so instead of getting more inter-app consistency (say you want to set the same keys as other browsers) you get more inconsistency.

Even just a JSON (like in VSCode) for advanced users would be fine at this point, proper UI can be an afterthought.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: