Closed
Bug 102993
Opened 24 years ago
Closed 1 year ago
Should be able to rebind xul-based accelerators.
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
INVALID
mozilla1.0.1
People
(Reporter: wdc, Unassigned)
References
Details
(Whiteboard: domcore-bugbash-triaged)
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•24 years ago
|
||
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
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Comment 3•24 years ago
|
||
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!
Reporter | ||
Comment 4•24 years ago
|
||
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
Updated•24 years ago
|
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 5•23 years ago
|
||
*** Bug 192046 has been marked as a duplicate of this bug. ***
Comment 6•23 years ago
|
||
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•23 years ago
|
||
> 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•23 years ago
|
||
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•17 years ago
|
||
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.
Updated•16 years ago
|
QA Contact: bugzilla → keyboard.navigation
Updated•16 years ago
|
Assignee: hyatt → nobody
Comment 10•15 years ago
|
||
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
Comment 11•7 years ago
|
||
Is this the same as bug 57805?
Assignee | ||
Updated•7 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
Whiteboard: domcore-bugbash-triaged
You need to log in
before you can comment on or make changes to this bug.
Description
•