Bug 58175

Summary: WebKit2: Safari doesn't respect cmd-arrows (and variations) as custom keyboard shortcuts
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: WebKit2Assignee: Alexey Proskuryakov <ap>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, darin, enrica
Priority: P2 Keywords: InRadar, Regression
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.6   
Attachments:
Description Flags
proposed fix none

Description Alexey Proskuryakov 2011-04-08 16:38:51 PDT 
When Cmd+Option+Arrows are configured as tab switching shortcuts, WebKit sometimes incorrectly performs a Back instead.

<rdar://problem/9060555>
Comment 1 Alexey Proskuryakov 2011-04-08 16:49:08 PDT 
Created attachment 88898 [details]
proposed fix
Comment 2 Darin Adler 2011-04-08 17:24:16 PDT 
Comment on attachment 88898 [details]
proposed fix

View in context: https://bugs.webkit.org/attachment.cgi?id=88898&action=review

> Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:545
> +    if (selector == "moveUp:")

I’d prefer if this was handled with some sort of hash table. I really wish there was a way to leverage the editor command machinery for this.
Comment 3 Alexey Proskuryakov 2011-04-08 17:29:04 PDT 
Maybe we can decide to just make Editor implement these behaviors when the focus is in non-editable content. This seemed weird to me, but I can't really explain why.
Comment 4 WebKit Commit Bot 2011-04-08 18:59:41 PDT 
Comment on attachment 88898 [details]
proposed fix

Clearing flags on attachment: 88898

Committed r83372: <http://trac.webkit.org/changeset/83372>
Comment 5 WebKit Commit Bot 2011-04-08 18:59:44 PDT 
All reviewed patches have been landed.  Closing bug.
Comment 6 Alexey Proskuryakov 2011-04-08 19:06:44 PDT 
A long-standing issue that this accidentally fixes is that other standard key bindings for the same commands didn't work. For example, Ctrl+P scrolls a non-editable TextEdit document up, but that didn't work in Safari before.