Closed Bug 412666 Opened 14 years ago Closed 14 years ago

make an effort to scroll tabstrip to show new tabs opened in background

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 beta5

People

(Reporter: mnemo, Assigned: dao)

References

Details

(Whiteboard: [morph in comment 3])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

(the exact numbers in these repro steps will probably be different depending on how wide your screen is)

First off all, the "sliding TABs animation" is a very good solution to the hidden TABs problem. I have been annoyed about this so many times in ff2. I was amazed and delighted that the devs had also noticed this and introduced this TAB slide animation feature.

Note that the current ff3 behavior I'm describing below doesn't have to be characterized as a bug. It's just that I think that the behavior change I'm suggesting below at the end would improve UX. I'll see if you agree with this or not (I hope you do).

1. Start firefox with a new empty window
2. Press CTRL-T four times so that you have 5 empty tabs (on my screen this fills up the whole screen width)
3. Press CTRL-T another 8 times so you got a total of 13 empty tabs open (on my screen this still only consumes one screenfull of width because the tabs get more arrow and squeeze in there)
4. Press CTRL-T again. this triggers an animation where the existing tabs are slided to the left and the new tab is inserted in the right most position (the tab that was previously left-most becomes hidden but there are arrow-buttons that allow the user to access hidden tabs).
5. (just as a note; if you click a link a IRC program or in thunderbird at this point it switches to firefox, runs the sliding animation while the new tab is inserted)
6. Now, in this right-most empty tab open cnn.com (or some page with links)
7. Right-click any normal web link on the front page and select "open link in new TAB"

At this point the new TAB is created but it's hidden to the right of the right-most TAB. Usually I open links "in a new TAB" because I'm going to be looking at that particular page very soon so I'd actually prefer this behavior:

When "open link in new TAB" is used the slide animation runs so that this new tab becomes visisble-and-clickable but not active (i.e. so I can click it to switch to it fast without using the arrow-buttons to first make that TAB visible and then click it to show that TAB).

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
You mean that it should scroll to the unfocused tab that is opened in the background? Don't you think this would give problems if the CNN home page was opened in the first tab? Sorry if I misunderstood... not native English speaking.
That's a good point, if CNN is the first tab it might be scrolled so far left that it becomes hidden. This would indeed be very bad.

I wonder if there is a way to solve the problem without running into this problem. The point I made about "soon wanting to activate" the 'open in new tab'-TAB is still valid even though my suggestion for a fix introduces another (worse) problem.
There may be a dupe on this, but I'm morphing it a little.

Now that we have smooth tab scrolling, we should make an effort to put new background tabs in view when they're opened. Even if both the active and new tab can't be seen in a single tabstrip width, we should scroll the tabstrip over so the current tab is at the far left side (or right in RTL) and in order to call attention to the "new tab out of view" fade animation.

An example, where we have a tabstrip of a width that can show 4 tabs:

 - user has five tabs open, four showing, is focusing on tab 3

| tab 1 (x)| tab 2 (x) || tab 3 (x) || tab 4 (x) |->|v|

 - user opens new tab 5 in background
 - tab strip scrolls one position to the right to show new tab:

| tab 2 (x)|| tab 3 (x) || tab 4 (x) | tab 5 (x) |->|v|

 - user focuses tab 1, then tab 2:

| tab 1 (x)|| tab 2 (x) | tab 3 (x) || tab 4 (x) |->|v|

 - user opens tab 7 in background
 - tab strip scrolls one position to go as far towards new tab as possible
 - -> marker animates

|| tab 2 (x)|| tab 3 (x) | tab 4 (x) || tab 5 (x) |->|v|

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-firefox3+
Summary: no "new tab" animation for "open in new tab" → make an effort to scroll tabstrip to show new tabs opened in background should
Whiteboard: [morph in comment 3]
(oops, small error in the ASCII art above, where I said "tab 2" was focused then drew focus on tab 2 and 3 ..)
Summary: make an effort to scroll tabstrip to show new tabs opened in background should → make an effort to scroll tabstrip to show new tabs opened in background
Attached patch patchSplinter Review
as per comment 3
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #306104 - Flags: review?(mano)
OS: Windows 2000 → All
Hardware: PC → All
Version: unspecified → Trunk
Comment on attachment 306104 [details] [diff] [review]
patch

looks good, thanks!
Attachment #306104 - Flags: review?(mano) → review+
Comment on attachment 306104 [details] [diff] [review]
patch

a=beltzner for after beta 4
Attachment #306104 - Flags: approval1.9+
Keywords: checkin-needed
Checking in browser/base/content/tabbrowser.xml;
/cvsroot/mozilla/browser/base/content/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.263; previous revision: 1.262
done
Checking in toolkit/content/widgets/scrollbox.xml;
/cvsroot/mozilla/toolkit/content/widgets/scrollbox.xml,v  <--  scrollbox.xml
new revision: 1.32; previous revision: 1.31
done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Component: General → Tabbed Browser
Keywords: checkin-needed
QA Contact: general → tabbed.browser
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3
Just started noticing this in nightlies. It's awesome.
Status: RESOLVED → VERIFIED
Target Milestone: Firefox 3 → Firefox 3 beta5
Flags: in-litmus?
Duplicate of this bug: 347315
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.