XUL/XBL modifier key needs to be settable through style

VERIFIED FIXED in M18

Status

()

P2
major
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: akkzilla, Assigned: akkzilla)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][p:2])

(Assignee)

Description

19 years ago
The XUL key used to be set in the <keyset> tag in the xul file, but hyatt
changed it to be temporarily hardwired by platform.  This needs to be made
configurable again, so users can choose their keybindings.

I thought there was already a bug on this, but my bugzilla queries haven't
turned one up.  Please dup as necessary.

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M14

Updated

19 years ago
Target Milestone: M14 → M15

Comment 1

19 years ago
Not needed for 2/15 beta.

Updated

19 years ago
Blocks: 13016
(Assignee)

Comment 2

19 years ago
Because of 23575, Hyatt apparently just switched the control key for Unix back
to control.  This reopens 18033 (which was a dogfood bug at the time and got a
large number of bugzilla votes) and takes us from a place where most people are
happy (they have their standard control-key cut/copy/paste bindings that they're
used to on other platforms, plus the emacs-style editing bindings which are also
supported on most platforms) to a place where people who are used to the old
Unix bindings are just out of luck.

I had previously made the xul key settable; I'll volunteer to work with hyatt
until it is again.
Keywords: beta1

Comment 3

19 years ago
Does making the change to CTRL hose emacs key bindings?  Keep in mind that I 
also reversed the order of events for the XUL accelerators vs. XBL input fields, 
i.e., if CTRL+X is defined in the menu and you're busy typing in a text field, 
CTRL+X will mean whatever the text field wants it to mean and not the other way 
around.

So can't we still have emacs key bindings in input fields?  I guess composer 
(with its many menu commands) may be more of an issue.  

I'm happy to change it back to ALT if it's the better default.  I was under the 
impression German had decided CTRL.

Comment 4

19 years ago
hyatt and akanna, can you two get together and decide the right thing for beta1. 
 Please let us know - pdt.

Comment 5

19 years ago
Putting on PDT- radar for beta1.  Would not hold beta for this bug.
Whiteboard: [PDT-]

Comment 6

19 years ago
Nah.  We just put Linux back on ALT patrol.  Shouldn't need this by beta1.

Comment 7

19 years ago
the consensus was the Ctrl be the shipping default and that at a later time we 

would make this configurable. (see other rel. bugs and newsgroup discussions)

(Assignee)

Comment 8

19 years ago
Making control the default and making it non-configurable would be a major
functionality loss for Unix users used to 4.x or the current mozilla.  Also
pointless, since the text field/area key bindings (including the
Windows-compatible ones) are hooked up and working now, but key bindings in the
browser and mail don't even exist yet, so we'd be disabling existing
functionality in order to get nothing in return.

When browser and mail/news enable their key bindings, I can make a pref to make
the modifier key switchable until we get the xul key in place.
spam: added self to cc list, as this would affect my area.

Updated

19 years ago
Blocks: 22515

Comment 10

19 years ago
moving to m17
Target Milestone: M15 → M17

Comment 11

19 years ago
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
(Assignee)

Comment 12

19 years ago
If this isn't going to make it by beta2, maybe we should just give up on the
idea of setting it through CSS, and I should put it on a pref.  We should really
try to freeze this sort of interface before beta2 so people don't have to
rewrite their ui files after that.

Hyatt, could you comment?  I can take this over and put it on a pref if you
don't have time to decide on the appropriate CSS tag for it.

Comment 13

19 years ago
key-equivalent is the appropriate CSS property.  I'll pull this in.
Target Milestone: M18 → M17

Updated

19 years ago
Target Milestone: M17 → M16

Updated

19 years ago
QA Contact: paulmac → jrgm

Comment 14

19 years ago
*** Bug 34234 has been marked as a duplicate of this bug. ***

Comment 15

19 years ago
Sigh.  Have to push out.  Overloaded with feature work.
Target Milestone: M16 → M17
(Assignee)

Comment 16

19 years ago
Changing summary to mention XBL so that it's clear that both XUL and XBL
bindings need to use this (should these be two separate bugs?)
Summary: XUL key needs to be settable through style → XUL/XBL modifier key needs to be settable through style

Comment 17

19 years ago
nominating for b2
Keywords: beta1 → nsbeta2
Whiteboard: [PDT-]

Comment 18

19 years ago
[nsbeta2-], might consider a small (including UI work), well-understood, safe 
implementation post beta2.
Whiteboard: [nsbeta2-]

Comment 19

19 years ago
Mass-moving all nsbeta2- bugs to M20
Target Milestone: M17 → M20
(Assignee)

Comment 20

19 years ago
Adding nsbeta3 keyword.  We're getting a LOT of demands from the various
different sides of the Unix community for things like menu access keys, or a
different access key on Sun, which cannot be solved until this is fixed.

I keep offering to make it a pref, and Hyatt keeps saying "No, it's trivial,
I'll do it the right way" and then somehow the bug gets bumped off again.  We
need to do this one way or another (preferably the right way, which I'll be glad
to implement instead of a pref if Hyatt will just tell me what that is).
Blocks: 27644
Severity: normal → major
Keywords: nsbeta3
(Assignee)

Comment 21

19 years ago
Okay, I'll take this, and make it a pref or something (unless Hyatt tells me a
better plan).
Assignee: hyatt → akkana
Status: ASSIGNED → NEW
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M20 → M18
(Assignee)

Updated

19 years ago
Keywords: nsbeta2 → correctness
Whiteboard: [nsbeta2-]

Comment 22

19 years ago
setting to nsbeta3+
Whiteboard: nsbeta3+

Comment 23

19 years ago
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]

Comment 24

19 years ago
setting priority in status whiteboard
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p:4]

Updated

19 years ago
Priority: P4 → P2
Whiteboard: [nsbeta3+][p:4] → [nsbeta3+][p:2]
(Assignee)

Comment 25

18 years ago
Fixed.  The name of the prefs are ui.key.acceleratorKey (for the accelerator,
i.e. "xul", key) and ui.key.menuAccessKey (for the menu access key).  Setting
either one to zero disables that functionality (e.g. no menu access key on
classic Unix or on current Mac).  These are int prefs, and the values are the
keycodes a la MouseKeyEvent.idl; ctrl is 17, alt is 18, meta is 224.  All
non-Mac platforms default to the Windows settings.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
adding others who might be interested in this feature. yay, akkana!

Comment 27

18 years ago
This appears to have regressed since 9/21.  Setting the pref no longer has any 
effect.

Comment 28

18 years ago
The accelerator pref changed to be "ui.key.accelKey" for reasons that are 
opaque to me (bug 53096). I assume there was a good reason. With today's 
linux branch build, I can swap the roles of ALT and CTRL for the menu
access and accelerator keys. (However, I can't seem to get this to work
on Windows right now).

Let me know if that is not working for you (the revised pref name). 

(To be clear, the other pref is still named "ui.key.menuAccessKey").

Comment 29

18 years ago
Great - the new pref name works fine on Solaris.  Thanks!
vrfy fixed, at least using linux bits for the past coupla weeks. :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.