Open Bug 941061 Opened 11 years ago Updated 2 years ago

New rounded tabs cause tab sliding arrows to work incorrectly

Categories

(Firefox :: Tabbed Browser, defect)

28 Branch
x86_64
Windows 7
defect

Tracking

()

People

(Reporter: roman.rellum, Unassigned)

References

Details

(Whiteboard: [Australis:P-])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131120030202

Steps to reproduce:

After new Australis UI update (FF 28) tab arrows (slide left/right) appear even when they are not needed. 

Screenshots of the issue:

http://fii.cz/ftkxegb -29 tabs (No arrows) correct behavior

http://fii.cz/zjhgm - 30 tabs (Arrows appear but you cant slide tabs yet, tabs move only by few pixels when you click left arrow. Then you can click right arrow to move them by few pixels back.) Situation is same up to 42 tabs (you still can see all 42 tabs in tab bar, left/right arrow move tabs for only few pixels.

http://fii.cz/bpbwyt - 43 tabs (arrows are needed because more tabs simply does not fit into tab bar)

Please note that I'm using following css code to make minimum tab width smaller than by default (worked correctly before Australis update, and I believe its not cause of the issue):

.tabbrowser-tab:not([pinned]) {
   min-width: 40px !important;
}

I think that arrows appear because of new rounded corner of tabs. As you can see on this screenshot http://fii.cz/hdtsdq rounded corner of rightmost tab is partially hidden. You can move tabs to left just as much is needed to reveal whole rounded corner of rightmost tab.



Actual results:

I think that sliding arrows shouldn't be brought up because rounded corner does not fit into tab bar. They should be brought up because you exceeded number of tabs which fit into tab bar.
Jared, is there anything we can do here?
Component: Untriaged → Tabbed Browser
Flags: needinfo?(jaws)
Not a whole lot we can do here with a simple fix. I've seen this too.

Ironically, the addition of the |<| and |>| are part of the cause for this. Potentially we could not show the arrows in this case, but there is potential that when hovering the tab that is being clipped part of the rounded side of the tab will be clipped.

Being smarter about when we show the arrows won't fully fix the issue, it only seems like a better fix when the tabs are smaller (40px). If we went with a robust fix, then we'd also want to fix the case where tabWidth/2 was overflowing (not any extra tabs overflowing).

I think it's only worth looking in to adjusting the code that determines if the overflow arrows should be shown.
Flags: needinfo?(jaws)
How abount kill the sliding arrow:
http://worldofgnome.org/tabs-design-in-gnome-3/
Whiteboard: [Australis:P-]
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131120030202

Reproduced this issue using the STR from comment 0. Marking as new.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.