Closed Bug 180840 Opened 21 years ago Closed 9 years ago

Support evt.accelKey as boolean property

Categories

(Core :: DOM: Events, enhancement)

Product:
Core
Component:
DOM: Events
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: WeirdAl, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

testcase
485 bytes, text/html
Details 
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: 9 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.