302419 - key element order is significant

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Shane Caraveo]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Having two key elements with the same key attribute, the first key seems to take
precedence.  for example:

        <key id="Meta+?" key="/" modifiers="meta" oncommand="alert('minor help');"/>
        <key id="Meta+Shift+?" key="/" modifiers="meta,shift"
oncommand="alert('major help');"/>

The above will always cause the first key to fire, even when hitting
Meta+Shift+/ (ie. Cmd+Shift+?)

Simply reverse the two elements, and they act as you would expect.

Reproducible: Always

Comment 1

[Shane Caraveo]

to take this one step further, if you dynamically modify key elements from
javascript, the order in which you modify them matters.  Using the same key
elements from the last bug entry:

document.getElementById('Meta+?').setAttribute('oncommand', 'alert("minor help");');
document.getElementById('Meta+Shift+?').setAttribute('oncommand', 'alert("major
help");');

the above fails, reverse the order of the two lines, and it works.

Comment 2

[Shane Caraveo]

one last note, I beleive this is osx specific, as this problem only showed up
during working our Komodo port or osx.

Comment 3

[Shane Caraveo]

change to toolkit per suggestion from #firefox irc

Comment 4

[Shane Caraveo]

I think I know why this is happening.  First, in
nsXBLPrototypeHandler::KeyEventMatched, if the charCode matched, then the shift
modifier is removed from the modifiers mask if the binding does not specify a
shift modifier.  This is logical from one point of view, but it does not find
the more specific handler later in the list of handlers.

The second part of the issue is that for certan keys, the charCode is not
shifted.  For example, Meta+Shift+A will shift the charCode, but Meta+Shift+/
does not.  Another binding that does not shift the charCode is Ctrl+Shift+3.  I
think this will affect all keys that are not a-z, since those are the only keys
that get a shifted charCode.

Thinking about some of our past keybinding issues, this may actually be a cross
platform bug.

So the solution for us would be to patch nsXBLPrototypeHandler::KeyEventMatched
to remove the code that removes the check for the shift modifier.  

The other (preferable) option would be to change the event dispatchers (on osx,
nsMacEventHandler::InitializeKeyEvent) to provide shifted charCode's for any
keys that actually have them (and not just a-z).  The reason this is preferable,
is Meta+? on osx, which is the standard help binding.  Standard osx apps will
show Cmd+? in the menu, and mozilla bases the menu keybinding on the modifiers +
key attributes of the key element.  Using Meta+Shift+/ or Meta+Shift+? would put
the wrong characters into the menu.

For now, the first option will work for us in our builds.

I'm not sure what the 'correct' thing to do with key event dispatching is in
general, I just need to be able to create keybindings in xul for any key
combination.

Comment 5

[[e-mail]]

This was fixed on the (1.9) trunk by bug 295228?

Comment 6

[Dirkjan Ochtman (:djc)]

This should probably be resolved, right?

Comment 7

[Todd Whiteman]

Expired.