Bug 22409 - REGRESSION: cmd-shift-left/right don't switch tabs, instead select text
Summary: REGRESSION: cmd-shift-left/right don't switch tabs, instead select text
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P1 Normal
Assignee: Darin Adler
URL: http://www.google.de/
Keywords: InRadar, Regression
: 22501 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-21 11:47 PST by Alexander Kempgen
Modified: 2008-12-08 16:15 PST (History)
5 users (show)

See Also:


Attachments
patch, but needs regression test so not up for review yet (21.46 KB, patch)
2008-12-03 17:53 PST, Darin Adler
no flags Details | Formatted Diff | Diff
patch (59.64 KB, patch)
2008-12-08 14:36 PST, Darin Adler
sullivan: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kempgen 2008-11-21 11:47:12 PST
with nightly r38654, the shortcuts cmd-shift-left/right don't switch to the left/right tab anymore, but instead select the line of text left/right of where you last clicked.

to reproduce:
- open any 2 websites in tabs
- on one site, click anywhere
- cmd-shift-rightarrow doesn't switch to the next tab

interestingly though cmd-{} still works
Comment 1 Justin Garcia 2008-11-21 13:37:13 PST
I think this is as intended.  Not sure why cmd-shift-left/right arrow ever switched tabs atm.
Comment 2 Alexander Kempgen 2008-11-21 15:47:50 PST
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.
Comment 3 Darin Adler 2008-11-21 17:33:08 PST
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.
Comment 4 Darin Adler 2008-11-21 17:34:56 PST
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.
Comment 5 Mark Rowe (bdash) 2008-11-24 03:14:42 PST
<rdar://problem/6396381>
Comment 6 Mark Rowe (bdash) 2008-11-25 16:02:11 PST
*** Bug 22501 has been marked as a duplicate of this bug. ***
Comment 7 Alexander Kempgen 2008-11-25 19:09:16 PST
there are several reasons why you shouldn't remove cmd-shift-left/rightarrow from safari, but those should probably go to bugreporter.apple.com?
Comment 8 Max Ebert 2008-11-25 23:17:38 PST
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.)
Comment 9 John Sullivan 2008-12-02 11:41:47 PST
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.
Comment 10 Darin Adler 2008-12-03 12:15:29 PST
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.
Comment 11 Darin Adler 2008-12-03 17:53:44 PST
Created attachment 25728 [details]
patch, but needs regression test so not up for review yet
Comment 12 Darin Adler 2008-12-08 14:36:50 PST
Created attachment 25853 [details]
patch
Comment 13 John Sullivan 2008-12-08 15:13:13 PST
Comment on attachment 25853 [details]
patch

It's impressive how much more complex the new layout test mechanism is than the actual fix.
Comment 14 Darin Adler 2008-12-08 16:15:53 PST
http://trac.webkit.org/changeset/39114