355817 - Some Cmd+Shift+letter shortcuts are broken

Status: VERIFIED FIXED

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

Description

[Jesse Ruderman]

The following shortcuts don't work, and beep instead:

Cmd+Shift+R   force reload
Cmd+Shift+G   find previous

The following shortcuts do work:

Cmd+Shift+I   inspect page with dom inspector
Cmd+Shift+Z   redo

I'm guessing this is a regression from cocoa.

Comment 1

[Uri Bernstein]

Cmd+=, which used to work like Cmd+Shift+= (i.e., Cmd++), now also beeps at me. I assume it's the same issue.

Comment 2

[Karsten Düsterloh]

See also bug 355797.

Comment 3

[Jesse Ruderman]

For opening the Downloads window, Cmd+J doesn't work, but Cmd+Shift+J does.  Weird!  (Likely related to bug 340065.)

Comment 4

[Stefan [:stefanh]]

Hmm... "force reload" and "find previous" are not to be found in any menu.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So this is pretty much annoying the hell out of me.  If I don't shift-reload I clobber other people's bug changes, and if I do I'm forced to use the mouse...

Can we please do something about it?  Certainly by a few weeks from now so we don't ship an alpha with this?

Comment 6

[Mike Connor [:mconnor]]

badly broken keyboard shortcuts are definitely a 1.9 blocker, not sure how we're indicating alpha blocker status atm.

Comment 7

[Boris Zbarsky [:bzbarsky]]

We're indicating it via the status whiteboard [blocking1.9a1+], based on 1.9 triage meeting discussion.

Of course for that discussion to happen the bug needs to be blocking1.9?...  I'm taking the liberty of adding the alpha-blocking annotation, since that seems preferable to resetting the flag back to ?.  But please let's not unilaterally mark bugs a blockers, ok?

Comment 8

[Josh Aas]

I think we should take this off the alpha blocker list. This is part of a bigger problem, same thing as the problem we have with menubar-less dialogs.

Comment 9

[Josh Aas]

Attachment: fix v1.0

Here we intercept key commands as they make their way up the view chain, before they get to the menu system. Then, we call performKeyEquivalent on the main menu bar manually and if it returns yes we just let it handle it. If it returns no then we handle the event ourselves.

Comment 10

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 247688 [details] [diff] [review]
fix v1.0

sr=pink

Comment 11

[Josh Aas]

fixed on trunk

Comment 12

[Josh Aas]

*** Bug 350225 has been marked as a duplicate of this bug. ***