Open Bug 102993 Opened 23 years ago Updated 2 years ago

Should be able to rebind xul-based accelerators.

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect

Tracking

()

mozilla1.0.1

People

(Reporter: wdc, Unassigned)

References

Details

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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> hyatt for triage
Assignee: aaronl → hyatt
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
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
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 192046 has been marked as a duplicate of this bug. ***
No longer depends on: 77976
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.
QA Contact: bugzilla → keyboard.navigation
Assignee: hyatt → nobody
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

Is this the same as bug 57805?

Component: Keyboard: Navigation → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.