Capalized key to select action fails in 10.8

[iwhisperer]

Since Mountain Lion upgrade, 'allow capitalized key to select action' has not functioned e.g. 'T' set for 'move to trash'. Using 'set as default' contextual menu option has no effect.
ß69 (3932)

[skurfer]

To elaborate: Only the first keystroke fails when holding ⇧. (By which I mean it gets sent to the first pane instead.) Subsequent keystrokes are sent to the second pane as expected.

[philostein]

So, ⇧letter is supposed to just select the letter's default object and move the focus to pane 2 without changing the action?
⌘⇧letter executes the action as defined by pressing the letter in pane 2.

That makes sense. Just have to change my ingrained behaviour. :)

[skurfer]

Assuming you have "Allow capitalized keys to select the action" enabled…

No, holding down ⇧ and typing in the first pane should be equivalent to tabbing to the second pane and typing those same letters. So it should start changing the action from the first letter. It just keeps focus on the first pane and prevents you from having to tab. (Why anyone thinks holding one keystroke (⇧) is easier than just hitting one keystroke (⇥), I have no idea, but that's how it's supposed to work.)

⇧⌘[letter] should simply be a quicker way to do ⇥ [letter] ↩. I think that's what you were saying for that one.

[philostein]

Assuming you have "Allow capitalized keys to select the action" enabled…

Yes. :)

No, holding down ⇧ and typing in the first pane should be equivalent to tabbing to the second pane and typing those >same letters. So it should start changing the action from the first letter. It just keeps focus on the first pane and prevents >you from having to tab. (Why anyone thinks holding one keystroke (⇧) is easier than just hitting one keystroke (⇥), I >have no idea, but that's how it's supposed to work.)

That's what used to happen in ß68. Now, ⇧[letter] does: [change object] then ⇥

⇧⌘[letter] should simply be a quicker way to do ⇥ [letter] ↩. I think that's what you were saying for that one.

Yes, that still works.

I don't mind the new behaviour TBH, it's simple to define an action with a letter in pane 2, then subsequently run the command using ⌘⇧letter.

[skurfer]

Don't understand that last comment. :-) The behavior for ⇧⌘[letter] is unchanged. It's the behavior for just ⇧ that's broken.

[philostein]

Yes, that's why the broken ⇧ isn't a big deal. Actions found with 1 letter can be run with ⇧⌘letter. Actions found with 2 letters now means tabbing to pane 2 and typing 2 letters. As you said, hardly more effort than the (broken) hold ⇧ and type the 2 letters. I can't remember ever doing the latter, anyway.

[skurfer]

This appears to be a bug in 10.8. The interpretKeyEvents: method should call insertText: on the same object, but in the "transcript" below, you can see that the first capitalized letter is sent to a different object (the first pane, in fact).

0x107b5c9a0 interpretKeyEvents: r
0x107b5c9a0 insertText: r
0x107b5c9a0 interpretKeyEvents: ⌫
0x107b5d360 interpretKeyEvents: S
0x107b5c9a0 insertText: S
0x107b5d360 interpretKeyEvents: G
0x107b5d360 insertText: G
0x107b5d360 interpretKeyEvents: ⎋

I had @pjrobertson try this on 10.7, and the messages are sent to the right place. I'll report it to Apple.

[skurfer]

Opened bug 12463358 with Apple.

[pjrobertson]

Just looked at this on 10.9 and still problematic. @skurfer any news on the radar report? Might be easier to see now that Apple have finally updated Radar... I wonder if it still requires "Safari 1.0 or higher" :P

I looked into it further and it seems that even though the first responder is correctly being changed the input manager doesn't pick it up. I changed the insertText: method to always send the text to the first responder and it seemed to work, but it isn't technically right since there might be cases where you want to send text to not the first responder.

Perhaps the correct solution would be to change handleShiftedKeyEvent: to call insertText: directly instead of keyDown:. I'm not sure if anything else could ever be send to handleShiftedKeyEvent: that isn't meant to be typed. Maybe a space? (if you press ⇧␣). But other things like ⇧↩ would already be handled so this might be the only exception (which we could account for)