Closed
Bug 628235
Opened 13 years ago
Closed 11 years ago
Moving selected tab to another group should still display selected tab
Categories
(Firefox Graveyard :: Panorama, defect)
Firefox Graveyard
Panorama
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: fryn, Unassigned)
References
Details
(Keywords: ux-consistency, ux-userfeedback)
Steps to reproduce: 1. Open two tabs. 2. Select the right tab. 3. Right-click the right tab, and select "Move to" -> "New Group". Expected result: The selected tab is still selected and displayed its new group. Actual result: Only the left tab is left, with no visual indication of where the formerly selected tab went. (For users unfamiliar with Panorama, this might be perceived as dataloss.) An example of existing tab movement feedback: When moving a tab to another window, the newly created window becomes active. An advantage of the current behavior: User selects a tab to examine its contents before moving it. User moves the tab to another group. Now, the user can quickly select other tabs in the current group to view or move. A disadvantage of the current behavior: User moves the selected tab. It was selected, which is an indication that the user still wants to look at the tab's contents, but now it takes several keypresses or clicks to get back to it.
Reporter | ||
Comment 1•13 years ago
|
||
This issue will be mitigated by the fixing of bug 626525.
See Also: → 626525
Comment 2•13 years ago
|
||
Another advantage of the current model is that we can right-click on tabs that we are not currently viewing and move them to other groups. It's true that we are optimizing for the above case instead of "I am viewing this tab, which I'd now like to move to another group and follow it there", but I think it's a more common/useful case. I'd be open to making the behavior different depending on if you were acting on a tab that you were or were not viewing. i.e. keep the existing behavior if you right click on a tab that you are not viewing, and use your proposed behavior when you right click on a tab that you are currently viewing. Assigning to Faaborg for some ux thoughts.
Assignee: nobody → faaborg
Priority: -- → P3
Target Milestone: --- → Future
Comment 3•13 years ago
|
||
Just a thought (let's discuss a bit more before we implement anything): What if background tabs just disappeared when moved, but if you were to do the action on the active tab (or in the future a set of multiple selected which includes the active tab) we zoomed out, quickly animated the move, and then zoomed back in with the new set of surrounding tabs. It's a bit Google earth, but might help users build up a better mental model of where they are.
Comment 4•13 years ago
|
||
Google earth indeed! My concerns are (a) that, with our current zooming animation speeds, it'd either be very choppy (and unclear what we're doing) or take too long and (b) this would take too long for beta 11 timeline.
Comment 5•13 years ago
|
||
yeah, I was thinking more Firefox 5 with that suggestion
Comment 6•13 years ago
|
||
I was just thinking on this, before even seeing this bug, of creating another bug about adding menu items new tab menu to manage tabs or organize tab groups, that would really help this issue, make it possible that users can find Panaroma in the first place from the Firefox Menu. Why didn't we of needing menu items for Panorama being the obvious necessity for users and not just tab->move hope I find where it went?
Comment 7•13 years ago
|
||
(In reply to comment #3) > Just a thought (let's discuss a bit more before we implement anything): > > What if background tabs just disappeared when moved, but if you were to do the > action on the active tab (or in the future a set of multiple selected which > includes the active tab) we zoomed out, quickly animated the move, and then > zoomed back in with the new set of surrounding tabs. > > It's a bit Google earth, but might help users build up a better mental model of > where they are. Sounds like a good way to address Fryn's complaint and build associations with what's actually happening. Granted we can get zoom fast/pretty enough, I like it.
Reporter | ||
Comment 8•13 years ago
|
||
(In reply to comment #3) Awesome! (CC'ing you, in case the assignee value gets replaced with an implementer.)
Reporter | ||
Updated•13 years ago
|
Keywords: ux-userfeedback
Whiteboard: ux-feedback
Reporter | ||
Updated•12 years ago
|
Reporter | ||
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•