359804 - Opening or closing sidebar resets tab bar scroll position

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Chris Connett]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

When I have enough tabs open so that Firefox is drawing them at their minimum width, if I scroll to the end of the tab list (possibly a long scroll) then open a bookmark in the sidebar, the scroll position of the tabs is reset to zero: i.e. the leftmost tab in the list is aligned to the left, even if the tabs were scrolled all the way to the right.  

Reproducible: Always

Steps to Reproduce:
1. Open tabs until you have to scroll through them.
2. Scroll to the right until the leftmost tab is not shown.
3. Open (or alternatively close an already opened) sidebar.

Actual Results:  
The leftmost tab of the list is shown 

Expected Results:  
A few possibilities come to mind.

* Keep the rightmost drawn tab the same.
* Expand equally the range of indices of drawn tabs.

There could probably be usability arguments for some other schemes, but the current behavior definitely feels wrong.

When the window is horizontally resized by the window manager, a similar bug occurs, except the tab scroll position is set so that the rightmost tab is drawn at the right.

Comment 1

[[:Aleksej]]

WFM on both
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1

Comment 2

[Chris Connett]

Apparently I misunderstood the behavior.  After further investigation, the behavior is to set the currently drawn tab range so the active tab is in view.  I had the leftmost tab selected in one test, and the rightmost tab selected when I checked the window manager resize.

Nevertheless, I found this behavior non-intuitive (which led to the bug report).  Perhaps the active tab shouldn't be forced into view on a redraw?

Comment 3

[[:Aleksej]]

While trying to reproduce this bug, I've found that the active tab doesn't become visible if you enter a URL and load it. That's where I think it should be forced to become visible. The question is, how many people think it should not.

Comment 4

[Steve England [:stevee]]

Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!

Comment 5

[Chris Connett]

I still experience this behavior with Firefox 2.0.0.4, on both Linux (Gentoo binary package, firefox-bin), and on Mac OS X 10.4 PPC.  Opening or closing the sidebar, or resizing the window, forces the currently active tab to be visible.

Comment 6

[[:Aleksej]]

The active tab becomes visible with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070623 Minefield/3.0a6pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5pre) Gecko/20070623 BonEcho/2.0.0.5pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Comment 7

[Wayne Mery (:wsmwk)]

Do you still see this problem using Firefox 3.5?  Please update the bug, and close/alter bug if appropriate.

Comment 8

[Dão Gottwald [:dao]]

This is still an issue.

I think the sidebar should actually expand beneath the tab bar, leaving the tabs alone.

Comment 9

[Chris Connett]

While the behavior remains the same, the movement of the tabs is now animated, so it's clear what's happening now.  I guess my biggest problem with the old behavior is that I didn't know what was happening to move the tab bar scroll.  I also see now why that behavior might be preferred: If the sidebar opens a link it will open in the currently selected tab, so seeing the tab that could get clobbered is a good thing.

I'm happy with the behavior now that it's animated, so I'll mark it resolved.  Comment #8 can be filed as a feature request if the poster wishes.

Comment 10

[Dão Gottwald [:dao]]

The fact that you're ok with it doesn't mean it's resolved.

Comment 11

[Dão Gottwald [:dao]]

fixed by bug 347930