70630 - reduce keybindings by allowing modifiers to be ignored

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P4)

Description

[Kathleen :Brade]

We could reduce the number of keybindings we need to specify if we could use 
"ignore*" in the modifiers attribute.  These variants would ignore the state of 
that particular modifier key for the purpose of matching.  I think we should add 
the following (or some similar set) to possible values for the modifiers 
attribute:
  * ignoreAlt
  * ignoreShift
  * ignoreControl
  * ignoreMeta

These could be used with any other values in the modifiers attribute except the 
modifier.  If "alt,ignoreAlt" were specified, the keybinding would be bad and 
shouldn't match anything (imo); it should probably be ignored and not maintained.

An example where we could use these in keybindings is in single-line editfields 
(input):  
  Pressing Home+Control should do the same thing as just Home
    Rather than defining a key for "home" and another for "Home + Control",
    we could just define one with "ignoreControl"

Comment 1

[David Hyatt]

I don't want to do this.  It runs counter to the concept of filtered handlers
that is specified in the XBL spec.

Comment 2

[David Hyatt]

It would be cleaner to do this with a separate ignore attribute that took the
same values as modifiers, e.g., <key keycode="VK_HOME" ignore="control"/>

How many duplicate keybindings are you having to define anyway?  I can't believe
that this is that big a problem.

Comment 3

[Akkana Peck]

The issue comes up on punctuation keys a lot, since you never know whether a
punctuation key (e.g. +) is going to be shifted or unshifted; so right now, we
have an accel-+ binding that has to be done three times, for accel-+,
accel-shift-+, and accel-= (the most common unshifted item below shifted plus).
We've also hit this on keys like home/end, return and delete, where users get
upset that the key doesn't do what they expect when a modifier is pressed, so we
end up having to define several combinations of bindings for some of these keys,
and we're often having to add small bugfixes for combinations that no one
thought of or thought people would hit.

Would the ignore= syntax also run counter to the filtered handlers idea?  (I
don't understand the conflict, but I don't want to add something that you think
would be inconsistent with the spec.)

Comment 4

[David Hyatt]

ignore= would be acceptable.

Comment 5

[Blake Ross]

cc'ing jesse, I think this is a better solution than the shift special-casing 
idea.

Comment 6

[timeless]

i like the ignore= idea.

Comment 7

[Jesse Ruderman]

This will require modifications to many files and will require coders to add 
ignore="shift" to many future keybindings.  Shift is usually ignored (when no 
other keybinding exists) whereas other keys are ignored infrequently.  Still, 
this is a more general solution.

(This bug for ignoring shift is bug 70140.)

Comment 8

[Akkana Peck]

We don't ignore shift now (though bug 70140 was a nice idea and I can certainly
understand why it was filed) so no existing key bindings would have to be
changed if this ignore= were allowed.  It would give us the opportunity to
coalesce several existing bindings which are defined both with and without
shift, however.

It also provides a mechanism for the feature requested in bug 70140 to be
implemented, if that were agreed upon; with the current code, I think that bug
would be very difficult to implement.

Comment 9

[Daniel Wang]

please open a discussion in the accessibility newsgroup on bug 56775 vs
this one.

I know this bug is assigned, but please don't implement yet.

bugs to be discussed:
bug 139106, bug 70140, bug 91094, bug 56775

Comment 10

[Akkana Peck]

Removing myself as assignee for editor bugs, since the editor project is (sadly) long gone.