342364 - don't scroll the tab strip on mouseover (unless we are dragging), make a click be necessary

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[(not reading, please use [e-mail] instead)]

should the scrolling tab strip scroll on mouseover, or should click be necessary?

spun off from bug #318168:

a good point from mark (who has a patch to make scrolling work for mac!):

he's wondering why we scroll on mouseover (and not requiring a click, see bug
#342229).   excluding the "while dragging" scenario, should we really scroll
automatically on mouseover of the scrollbox buttons like we do in menus?  or
should we behave more like a scrollbar.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

I haven't played with the scrolling tab strip yet (is it in nightlies?) but having it scroll on mouseover is definitely not the right way to go as the default interaction. It's a pleasant optimization when dragging a tab, but other than that, we should wait for a click.

Comment 2

[(not reading, please use [e-mail] instead)]

> I haven't played with the scrolling tab strip yet (is it in nightlies?) 

not yet, the patch is awaiting reviews.

> but having it scroll on mouseover is definitely not the right way to go as the
> default interaction.

I agree with you and mark.  (Thanks to mento for pointing this out!)

asking for blocking.  I hope to fix this before 318168 lands (or immediately after)

Comment 3

[(not reading, please use [e-mail] instead)]

updating summary.

for mouseover on drag, we'll still scroll by [x] pixels at a time (x defaults to 20, but there is a hidden pref to override)

for click, I'll go one tab at a time.

Comment 4

[(not reading, please use [e-mail] instead)]

the fix for this is now part of the fix for bug #318168

the only remaining piece is how to style the arrowscrollbox buttons on hover for both winstripe and pinstripe

Comment 5

[(not reading, please use [e-mail] instead)]

this will be fixed when bug #318168 is fixed, but leaving this bug open for future reference since the behavior on mouseover is discussed directly.

Comment 6

[(not reading, please use [e-mail] instead)]

this is fixed (on the trunk, at least).

Comment 7

[Marcia Knous [:marcia]]

Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060627 Minefield/3.0a1 I don't get the clickable behavior when I use the tab scroll that apparently is supposed to be present. Seth asked me to add my comments and reopen this bug.

Comment 8

[(not reading, please use [e-mail] instead)]

oops, I think I forgot to add the clicktoscroll attribute in the mac specific binding for scrollbox.xml

thanks marcia!  on it...

Comment 9

[(not reading, please use [e-mail] instead)]

Attachment: fix for pinstripe

Comment 10

[(not reading, please use [e-mail] instead)]

Comment on attachment 227288 [details] [diff] [review]
fix for pinstripe

switching review to ben.

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 227288 [details] [diff] [review]
fix for pinstripe

r=[e-mail]

Comment 12

[(not reading, please use [e-mail] instead)]

fix checked into the trunk.  I'll make a new patch for bug #318168 that includes this change.

Comment 13

[(not reading, please use [e-mail] instead)]

Comment on attachment 227288 [details] [diff] [review]
fix for pinstripe

seeking approval to land this (as well as the patch in bug #318168)

Comment 14

[Marcia Knous [:marcia]]

Looks good to me on the Mac using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060628 Minefield/3.0a1. I can now click on the widget to scroll the tab instead of yesterday's behavior when it was auto scrolling on hover.

Comment 15

[Mike Schroepfer]

Comment on attachment 227288 [details] [diff] [review]
fix for pinstripe

Approving on 1.8.1 branch for 1.8.1 drivers.

Comment 16

[(not reading, please use [e-mail] instead)]

fixed landed on the 1.8 branch.

thanks to marcia for verifying this on the trunk.