Closed Bug 156025 Opened 22 years ago Closed 14 years ago

Tab switching keybindings suggestion

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: gsasha, Unassigned)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020510
BuildID:    20020510

I suggest using the same keybindings that are used by default in KDE's konsole:

Shift-Left, Shift-Right switch between tabs
Ctrl-Shift-Left, Ctrl-Shift-Right move the tabs to the corresponding direction.

Even if you don't agree with this assignment of shortcuts because of conflicts,
I think that this approach to tabbed navigation (left, right, move tab left,
move tab right) is the paradigm that must be used.

Reproducible: Always
Steps to Reproduce:
This is not a bug; it is enhancement request
See bug 136915 for all the hot discussion
Depends on: Ctrl-Tab
You don't understand what tabs are. Grab a tab in a 3 X 5 cooking index, or a
kid's notebook with dividers, or manilla folders in a card file. Tabs are
nothing but a grippy for an up/down movement through a stack, not a real
left/right movement.

Ctrl PgUp/PgDn makes good sense. I suggest WONTFIX.
Rolodex is the word I forgot. Rolodex is the familiar parallel to tabs, up/down,
not left/right.

> Tabs are nothing but a grippy for an up/down movement
> through a stack, not a real left/right movement.

That may be the case in the real world, but it certainly doesn't look like that
in the Mozilla UI.  If it were made signifcantly more 3 dimensional then what
you say would be more intuitive.  But, the current UI suggests a group of pages
all laid out horizontally, one next to the other.  The one currently being
viewed is moved very slightly towards the viewer but, other than that, it's all
horizontal, two dimensional representation.  A rolodex it isn't.

I agree with Alex on this one.  As the interface stands, left / right seems far
more intuitive to me than up down.  I know immediately which key I should be
pressing to get to the tab on the left - whereas I have to think about things
for a while to make the connection that somebody thinks the tab on the left is
really "down".  (And, actually, up and down doesn't work that well with a
rolodex either since it's really closer and farther away - up and down don't
translate well to the concepts push and pull...)
I don't believe that this bug can be marked as depending on bug 136915. 
Normally a dependency means that a bug can only be fixed if another bug is first
fixed.  But in this case, each bug is requesting a different set of key
bindings.  They are mutually exclusive.  If one is marked FIXED, the other will
have to be closed as WONTFIX.  Therefore, either neither should be marked as
dependent, or both should.  (I don't even know if it's possible to have A
dependent on B and B dependent on A at the same time.)  But I suggest either
removing the dependency or creating a mutual dependency (if possible).
I agree with Jason (comment #4): just because the initial inspiration of tabbed
interface came from Rolodex, it doesn't mean we should be limited by it.

Just to note: on my computer (with the KDE default keybindings) Ctrl-TAB
switches desktops. I don't know about bindings in other setups, but it is often
used also.

Anyways, I don't see how Shift-Left/Shift-Right contradicts the Ctrl-Tab
assignment. In my opinion, both could be implemented at the same time, and
everyone would be happy.
I would personally have no problem with multiple key binding assignments - I
just don't know if that would be readily approved by the UI team.  I think it
would be a nice feature if key bindings were made dynamic and could be fully
customized from default settings by each user but, again, I'm not sure if that
would fly.

Still, if I HAD to choose between Ctrl-Tab / Ctrl-Shift-Tab and Shift-Left /
Shift-Right (ideally we could have both and/or choose which we wanted) I would
pick the latter as it has a more intuitive relationship to what the UI represents.
Confirming this bug as a valid enhancement request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Shift-left/right are used to select text on a page (I guess this is an
accessibility feature). How about alt+shift+left/right? (ctrl+left/right is used
to jump words, add shift to select the words you're jumping across).
Whatever. This is becoming complex, but I think that keyboard tabs navigation is
important enough for expert users.
...and Alt-Left/Right is for navigation.

I'd prefer Ctrl-Alt-Left/Right.  (It's easier to hit those two keys - and
Windows users should already be used to the combination from Ctrl-Alt-Del.)
you're about to collide with window managers which use those bindings for
shifting workspaces.

this is silly.

my proposal is to add the tab bar to the tab order.

from the urlbar,
ctrl-tab focuses the active tab
from there, ctrl-tab switches to the next thing (sidebar?, content)

in tabs bar:
* arrows walk tabs logically
* delete deletes selected tab(s)
* enter activates the focussed tab
* home/end or platform equiv (up/down on mac) go to the first/last tabs
* tab goes to the delete tab button
* shift-tab goes to the new tab button
* context key triggers context menu for focussed tab
* shift/ctrl+arrows can be used to create selections of tabs for use with
bookmark tabgroup or delete.

Jesse is opposed to this because it interferes with the tab cycle, but imo it
adds only one-ctrl tab (or three tabs) which isn't bad and it should allow
people to do all the tab walking they want.

open questions, do arrows automatically activate tabs or do you need to use
enter (as speced above). If arrows activate tabs automatically, then ctrl-arrows
would be needed to walk tabs w/o activating them.
> If arrows activate tabs automatically, then ctrl-arrows
> would be needed to walk tabs w/o activating them.

Now *that's* silly. <grin>  If Ctrl-Tab is going to be used to switch between
different UI elements then I could see this happening.  But the point of this
bug, and for those arguing in favour of making Ctrl-Tab switch tabs ONLY, is
that none of us want to "walk" tabs without activating.  We only want the
keyboard shortcut so that we can activate tabs left / right.  I would never have
a need to select a tab and not activate it with the keyboard.  (Closing a
non-selected tab can be easily done via tab context menus using the mouse.)

No, whatever keyboard shortcut is adopted here should not be mixed in with
changing UI elements - it should only be for selecting (and activation) tabs.
While timeless' suggestion does provide for a generic mechanism of accessing and
manipulating tabs, my problem with it is that it makes switching to the next or
previous tab a two step process. One step to get to the tab bar, then the second
step to switch. I much prefer ctrl+page-up/page-down over that.
QA Contact: sairuh → pmac
Product: Core → SeaMonkey
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.