Closed Bug 23587 Opened 25 years ago Closed 25 years ago

XUL/XBL modifier key needs to be settable through style

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: akkzilla)

References

Details

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

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.
Status: NEW → ASSIGNED
Target Milestone: M14
Target Milestone: M14 → M15
Not needed for 2/15 beta.
Blocks: 13016
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
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.
hyatt and akanna, can you two get together and decide the right thing for beta1. Please let us know - pdt.
Putting on PDT- radar for beta1. Would not hold beta for this bug.
Whiteboard: [PDT-]
Nah. We just put Linux back on ALT patrol. Shouldn't need this by beta1.
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)
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.
Blocks: 22515
moving to m17
Target Milestone: M15 → M17
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
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.
key-equivalent is the appropriate CSS property. I'll pull this in.
Target Milestone: M18 → M17
Target Milestone: M17 → M16
QA Contact: paulmac → jrgm
*** Bug 34234 has been marked as a duplicate of this bug. ***
Sigh. Have to push out. Overloaded with feature work.
Target Milestone: M16 → M17
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
nominating for b2
Keywords: beta1 → nsbeta2
Whiteboard: [PDT-]
[nsbeta2-], might consider a small (including UI work), well-understood, safe implementation post beta2.
Whiteboard: [nsbeta2-]
Mass-moving all nsbeta2- bugs to M20
Target Milestone: M17 → M20
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
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
Status: NEW → ASSIGNED
Target Milestone: M20 → M18
Keywords: nsbeta2 → correctness
Whiteboard: [nsbeta2-]
setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p:4]
Priority: P4 → P2
Whiteboard: [nsbeta3+][p:4] → [nsbeta3+][p:2]
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
Closed: 25 years ago
Resolution: --- → FIXED
adding others who might be interested in this feature. yay, akkana!
This appears to have regressed since 9/21. Setting the pref no longer has any effect.
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").
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.