RESOLVED FIXED 58175
WebKit2: Safari doesn't respect cmd-arrows (and variations) as custom keyboard shortcuts 
https://bugs.webkit.org/show_bug.cgi?id=58175
Summary WebKit2: Safari doesn't respect cmd-arrows (and variations) as custom keyboar...
Alexey Proskuryakov
Reported 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>
Attachments
proposed fix (11.10 KB, patch)
2011-04-08 16:49 PDT, Alexey Proskuryakov 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2011-04-08 16:49:08 PDT
Created attachment 88898 [details] proposed fix
Darin Adler
Comment 2 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.
Alexey Proskuryakov
Comment 3 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.
WebKit Commit Bot
Comment 4 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>
WebKit Commit Bot
Comment 5 2011-04-08 18:59:44 PDT
All reviewed patches have been landed. Closing bug.
Alexey Proskuryakov
Comment 6 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.
Note You need to log in before you can comment on or make changes to this bug.