I discovered this while trying to tweak a personal preference: I wanted to rebind the key <accel>o to what <accel><shift>l was bound to. Stated differently, to have ^o Open Location, rather than Open File. Apparently, because these accelerators are associated with menus, they are defined through xul, and there seems to be no way to rebind a key that is already bound in this way, nor is there a user-accesible handle on the 'pop up the Open Location dialog' function. Could such functions as Browser:Open (I hope I'm using the right name for the 'pop up the Open Location dialog thing.) be brought out and settable by users? Apparently a fix for bug #77976 is a prerequisite for having this functionality if xul has already bound something that a user wants to rebind.
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> hyatt for triage
Assignee: aaronl → hyatt
Being able to bind JS into keyboard would seem to open up a can of worm like good old ANSI bombs. How about adding the Browser:foobar-commands into the "command" command-list used in xml? Then you could use standard XBL stuff as you'd expect to be able to? I don't know where the command-list comes from, but it'd seem like a logical place to stick navigation functions into. Static/hard-coded keyboard definitons are not a GOOD thing like any FPS player will tell you. If maintaining a list of known commands in XBL/Insert-ini-interface-of-choice-here does not count against your sins in this world, it should!
When I initially tried to do this, I was groping for PRECISELY the solution Olli has recommended. Remember, though, successful implementation of rebinding depends upon XBL bindings being able to override XUL bindings. So I'm gonna mark this bug as depending on 77976. Strictly speaking, we all know that users will get substantial relief if JUST this bug is fixed. It's the total solution that requires 77976 as well. (People are welcome to correct me if I mis-understand and am mis-applying the dependency graph.)
Depends on: 77976
*** Bug 192046 has been marked as a duplicate of this bug. ***
It *is* possible to rebind xul-based accelerators. See http://www.mozilla.org/unix/customizing.html#keys for instructions. There is a remaining issue that bug 77976 does not cover: XUL bindings always override XBL bindings. (Bug 77976 is about another problem that is already fixed. I have removed this bug's dependency on bug 77976.) How can we fix the remaining issue of XUL bindings always overriding XBL bindings?
> From Jason Spiro > It *is* possible to rebind xul-based accelerators. See > http://www.mozilla.org/unix/customizing.html#keys for instructions. I believe this comment is incorrect. If I remap the ui.key.accelKey key to the alt key and put <key key="c" command="Browser:Back" modifiers="control"/> into res/builtin/userHTMLBindings.xml as per the Customizing Mozilla web page, then ^c does *not* do a Browser:Back. See 192046 for the full details. Perhaps I'm comparing apples with oranges? steve - - -
Steve, I agree; I was wrong. Comment 5 should have read: It *is* possible to edit the XUL file that specifies certain accelerator keys. By doing so, you can rebind, say, Edit | Copy from Ctrl-C to, say, Ctrl-M. See http://www.mozilla.org/unix/customizing.html#keys for instructions. There is a remaining issue that bug 77976 does not cover: XUL bindings always override XBL bindings. (Bug 77976 is about another problem that is already fixed. I have removed this bug's dependency on bug 77976.) How can we fix the remaining issue of XUL bindings always overriding XBL bindings?
Is something being done about this bug? I find it quite problematic that (in Linux at least) the accelerators for quiting firefox and closing a tab lie right next to each other (ctrl+q and ctrl+w). I use KDE and have removed the ctrl+q accelerator globally, but firefox doesn't respect that configuration, so I end up closing firefox accidentally.
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
Component: Keyboard: Navigation → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.