Bug 22409 – REGRESSION: cmd-shift-left/right don't switch tabs, instead select text

• Component: New Bugs
• Status: RESOLVED FIXED

[Alexander Kempgen]

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

[Justin Garcia]

I think this is as intended.  Not sure why cmd-shift-left/right arrow ever switched tabs atm.

[Alexander Kempgen]

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.

[Darin Adler]

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.

[Darin Adler]

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.

[Mark Rowe (bdash)]

<rdar://problem/6396381>

[Mark Rowe (bdash)]

*** Bug 22501 has been marked as a duplicate of this bug. ***

[Alexander Kempgen]

there are several reasons why you shouldn't remove cmd-shift-left/rightarrow from safari, but those should probably go to bugreporter.apple.com?

[Max Ebert]

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.)

[John Sullivan]

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.

[Darin Adler]

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.

[Darin Adler]

Created attachment 25728 [details]
patch, but needs regression test so not up for review yet

[Darin Adler]

Created attachment 25853 [details]
patch

[John Sullivan]

Comment on attachment 25853 [details]
patch

It's impressive how much more complex the new layout test mechanism is than the actual fix.

[Darin Adler]

http://trac.webkit.org/changeset/39114