Summary: | REGRESSION: cmd-shift-left/right don't switch tabs, instead select text | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexander Kempgen <alex> | ||||||
Component: | New Bugs | Assignee: | Darin Adler <darin> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ap, darin, justin.garcia, realoreocookie, sullivan | ||||||
Priority: | P1 | Keywords: | InRadar, Regression | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.5 | ||||||||
URL: | http://www.google.de/ | ||||||||
Attachments: |
|
Description
Alexander Kempgen
2008-11-21 11:47:12 PST
I think this is as intended. Not sure why cmd-shift-left/right arrow ever switched tabs atm. cmd-{} dont work as shortcuts on german keyboard layouts, maybe thats why. i only have an english version of safari atm, so i can't check if there are alternatives to that, but if not cmd-shift-left/right are definately needed. The arrow keys used to switch tabs, but we changed that due to a conflict with the keyboard equivalents for selecting text. Making those commands for selecting text work even when the text area is not editable unintentionally broke Safari behavior. It's the correct, desired behavior in applications such as Mail that don't want to use those arrow keys for other purposes. This bug can be fixed in Safari rather than WebKit or we can change the WebKit behavior for Safari's benefit. Not sure which I should do. (In reply to comment #2) > cmd-{} dont work as shortcuts on german keyboard layouts, maybe thats why. i > only have an english version of safari atm, so i can't check if there are > alternatives to that, but if not cmd-shift-left/right are definately needed. The German version of Safari uses Option-Shift-Command-Ö and Option-Shift-Command-Ä — not sure where those are on a German keyboard. In general, I'm not sure how we handle the conflict when text editing binding commands conflict with menu commands. I can easily change this if I don't mind breaking the use of command-shift-left to select in non-editable text, but it seems a shame to do that only for the benefit of Safari and only for the obsolete secondary invisible key binding in Safari. *** Bug 22501 has been marked as a duplicate of this bug. *** there are several reasons why you shouldn't remove cmd-shift-left/rightarrow from safari, but those should probably go to bugreporter.apple.com? I use a US keyboard and a US keyboard layout, the shortcuts work just the same as with a German keybaord. I have reported it here, because it has worked fine in previous builds of WebKit and Safari (including the latest official release). Hence it seems to be related to the rendering engine which inserts a `cursor' to where you have clicked even though you cannot edit text. (If you have a text field, this would be expected behavior, though.) I can easily imagine wanting to use command-shift-arrow keys to extend an existing selection in non-editable text, and being frustrated if it went back/forward instead, even in Safari. But having command-shift-arrow keys go from no-visible-selection-(not-even-an-insertion-point) to one-character-selected seems not very useful. Maybe the best solution is to only use command-shift-arrow to extend the selection in non-editable text if the current selection has a non-zero length, and otherwise fall back to the old back/forward behavior. OK, I'm going to change this so that the change doesn't have any effect when the frame's selection is just an invisible position -- this should make most of the unpleasantness go away, although the conflict still does exist between the tab switching keys and selection-modifying keys. Created attachment 25728 [details]
patch, but needs regression test so not up for review yet
Created attachment 25853 [details]
patch
Comment on attachment 25853 [details]
patch
It's impressive how much more complex the new layout test mechanism is than the actual fix.
|