Last Comment Bug 102993 - Should be able to rebind xul-based accelerators.
: Should be able to rebind xul-based accelerators.
Status: NEW
:
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: Trunk
: All All
: -- normal with 6 votes (vote)
: mozilla1.0.1
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 192046 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-03 16:04 PDT by William Cattey
Modified: 2010-05-13 10:10 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description William Cattey 2001-10-03 16:04:38 PDT
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.
Comment 1 Akkana Peck 2001-10-03 17:41:49 PDT
Some more detail: user keybindings are xbl, not xul, and the Browser: bindings
(at least Open and Back) which are used by the xul bindings don't seem to be
accessible in xbl.  Further, javascript doesn't work in xbl bindings (it is
intended to, but apparently JS security policies or something similar are
interfering).

Probably should be Hyatt's bug; or else, he'll know who should own it.
Comment 2 Aaron Leventhal 2001-10-03 21:09:24 PDT
-> hyatt for triage
Comment 3 Olli Männistö 2001-10-08 10:44:59 PDT
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! 
Comment 4 William Cattey 2001-10-11 21:58:21 PDT
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.)
Comment 5 Akkana Peck 2003-02-07 13:07:26 PST
*** Bug 192046 has been marked as a duplicate of this bug. ***
Comment 6 Jason Spiro 2003-03-18 08:41:14 PST
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?
Comment 7 steve rader 2003-03-20 07:14:07 PST
 > 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
- - -
Comment 8 Jason Spiro 2003-03-21 09:26:18 PST
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?
Comment 9 Fernando Díaz 2008-09-03 09:25:23 PDT
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.
Comment 10 Michael Kohler [:mkohler] 2010-05-13 10:10:08 PDT
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.

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