Currently, a double-click on one of the arrows in the tab bar scrolls by the width of the tab bar, a triple click to the end of the tab bar. It was implemented in Bug 357951. In my opinion, this is not helpful and not intuitive. not helpful: Scrolling the tab bar by the tab bar width lets you loose your orientation. you do not experience the usual "when i scroll (left/right), the tabs on the (left/right) appear one by one", but the process is so fast that all tabs just get replaced, and you will have to reorientate. not intuitive: Who does EXPECT a double click on a scroll button to scroll the bar by the bar width? Nobody. Did you ever see any other scroll button who does that? My guess is, that the average user expects a double-click on that button to move the tab bar by twice the distance a single click does, but i agree that this is not the solution. My proposal: Make the scroll speed adaptive, i.e. dependent on the time distance between clicks. i imagined something like ((tab width) * 1/(seconds since last click)) With a maximum of i.e. tab width * 10 and a minimum of tab width * 1. That would mean 2 tab widths for 0,5 seconds up to 10 tab widths for 0.2 seconds, which is reasonable in my opinion. Of course there may be better algorithms, but this might be a good start :) A user would see, the faster he clicks, the faster the tab bar moves, which is intuitive. Additionally, this would be somehow in line with the mouse wheel behavior. The user can get a feeling for "faster clicks make the tab bar move faster", while "a double click scrolls the tab bar by the tab bar width" is nothing you can feel, but you find that out, and remember it the next time you double click the arrows and experience that nonintuitive behaviour.