Support evt.accelKey as boolean property




16 years ago
4 years ago


(Reporter: WeirdAl, Unassigned)



Firefox Tracking Flags

(Not tracked)




(1 attachment)



16 years ago
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

Opinions?  An accelKey property may be the "wrong" way to go about it, but it
would be simple.

Comment 1

16 years ago
Created attachment 110237 [details]

Comment 2

16 years ago
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?

Comment 3

16 years ago
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.

Comment 4

16 years ago
Control key on windows maps to ctrlKey property.

Comment 5

16 years ago
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)

Comment 6

16 years ago
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.

Comment 7

16 years ago
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.


15 years ago
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. ***

Comment 9

12 years ago
Don't forget BeOS, which IIRC swaps the Alt and Ctrl keys (so that Ctrl opens menus and Alt operates access keys).

Comment 10

10 years ago
except when it doesn't (BeOS lets the user choose :)
Assignee: events → nobody
QA Contact: ian → events
I suggested this attribute to W3C.
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.
Last Resolved: 4 years ago
Depends on: 1009388
Resolution: --- → INVALID

Comment 13

4 years ago
So, how to deal with the following code:

  <binding id="tree-base" extends="chrome://global/content/bindings/general.xml#basecontrol">
      <stylesheet src="chrome://global/skin/tree.css"/>
      <method name="_isAccelPressed">
        <parameter name="aEvent"/>
# Workaround until bug 302174 is fixed
#ifdef XP_MACOSX
          return aEvent.metaKey;
          return aEvent.ctrlKey;
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.