|Summary:||WebKit2: Safari doesn't respect cmd-arrows (and variations) as custom keyboard shortcuts|
|Product:||WebKit||Reporter:||Alexey Proskuryakov <ap>|
|Component:||WebKit2||Assignee:||Alexey Proskuryakov <ap>|
|Severity:||Normal||CC:||commit-queue, darin, enrica|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.6|
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.