Closed Bug 180840 Opened 22 years ago Closed 11 years ago

Support evt.accelKey as boolean property

Categories

(Core :: DOM: Events, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: WeirdAl, Unassigned)

References

()

Details

Attachments

(1 file)

I'm having some trouble canceling a keypress event in an XUL textbox which fires the undo command. My problem is I can do a combination of ((evt.ctrlKey) && (evt.keyCode == 96))... but that's not guaranteed to work outside of Windows. Other operating systems support other "accel" keys. The URL in this bug refers to the XBL document that defines the keystrokes referenced. It is here and in platformHTMLBindings.xml that I find the accel modifier defined. I'd rather intercept the keypress event for keys using the OS-independent accel modifier. This would make it possible for me to cancel the default action under any OS, so I could call an undo command in a different scope (such as DOM Inspector). Opinions? An accelKey property may be the "wrong" way to go about it, but it would be simple.
Attached file testcase
There is also the metaKey modifier that maps to special keys on different platforms. If you know of some special key on some platform that does not set metaKey, then it probably should, I think that would be a better solution. Can you please coment what platforms the special keys are not detected on?
At the moment I cannot -- I am away on vacation, and unable to do any Mozilla- related work at this time. I thought the meta key applied to the Macintosh meta key only. I'd be delighted to find out I was wrong. If the metaKey property reflects the control key on Windows platforms, I really have nothing to gripe about.
Control key on windows maps to ctrlKey property.
That's what I thought. As I indicated in my original bug report, what am I supposed to do for cross-compatibility with Linux or Macintosh platforms? :) (sarcasm and bitterness not intended)
You should do something like "if(e.ctrlKey || e.metaKey || e.altKey || e.shiftKey)" to check if one of the special keys is pressed. If there is a modifier key that does not map to any of these, that would probably be a valid bug, and I would say if it is not ctrl,alt or shift, it should be mapped to the metaKey according to the spec.
Great. User types shift + z to get a capital Z, and my event handler intercepts that. Or worse, alt + z, when that's mapped to something else. I already thought of that.
No longer blocks: 112922
Assignee: joki → events
QA Contact: vladimire → ian
Hardware: PC → All
*** Bug 302174 has been marked as a duplicate of this bug. ***
Don't forget BeOS, which IIRC swaps the Alt and Ctrl keys (so that Ctrl opens menus and Alt operates access keys).
except when it doesn't (BeOS lets the user choose :)
Assignee: events → nobody
QA Contact: ian → events
This is now INVALID. D3E WG decide that they won't add messy fooKey attributes anymore. Instead, getModifierState("Accel") should work as this. See bug 1009388. However, it needs more run-time cost than this approach because it takes a string argument. If this should be available only in chrome script for performance, please reopen this bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 1009388
Resolution: --- → INVALID
So, how to deal with the following code: <binding id="tree-base" extends="chrome://global/content/bindings/general.xml#basecontrol"> <resources> <stylesheet src="chrome://global/skin/tree.css"/> </resources> <implementation> <method name="_isAccelPressed"> <parameter name="aEvent"/> <body><![CDATA[ # Workaround until bug 302174 is fixed #ifdef XP_MACOSX return aEvent.metaKey; #else return aEvent.ctrlKey; #endif ]]></body> </method> </implementation> </binding>
aEvent.getModifierState("Accel") returns *similar* result. Which is an Accel modifier key depends on "ui.key.accelKey" at first call of WidgetInputEvent::AccelModifier().
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: