Closed Bug 393006 Opened 13 years ago Closed 13 years ago

Use a constant tab scrolling speed when holding down the scroll arrows

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 3 alpha8

People

(Reporter: ventnor.bugzilla, Assigned: ventnor.bugzilla)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached patch Patch (obsolete) — Splinter Review
Bug 347363 comment #83
> The current behavior for single click-release on the left and right arrows
> works great, but I share the same concerns in comment #81, that clicking and
> holding is now less efficient. 
> 
> What if we changed the single click-hold-release behavior to this:
> 
> -on downclick the tab strip begins to scroll smoothly (adding acceleration
> would be really cool, but a constant velocity would be fine too)
> 
> -on upclick, tab strip continues to scroll a little so that the tab nearest the
> button hit is fully visible.
Attachment #277512 - Flags: review?(enndeakin)
Would this need ui-r from mconnor? Alex has already advocated this approach and I'd rather not wait half a year for a ui-r again ;)
Neil, please review attachment 276942 [details] [diff] [review] first. The patches are not compatible, and I'm not sure if I'll have time sync them. (Could be trivial, but that's not a given.)

Michael, I haven't looked at your patch deeply, but I think you do need ui-review here. It's not so much about the theoretical solution, but the actual implementation. The old one in bug 347363 wasn't that great.
Attachment #277512 - Flags: review?(enndeakin) → ui-review?(mconnor)
what's the argument for constant vs. slowly accelerating?  In general, I'm ok with either, I guess I've been using mousewheel to scroll here anyway, so I'm not sure what exactly we're trying to fix here.
Hold down the left or right scroll button on the tab bar. People don't like what currently happens because its too slow, they want a constant scrolling speed.
Will this address the difference in speeds between clicking on the scroll arrow, vs dragging over the scroll arrow (the latter is currently much faster and lacks the "pulsing" nature of the click scroll... maybe smooth scroll wasn't implemented for it the same way?) Also, as noted elsewhere (I can't remember where), if you move the cursor around over the scroll arrow while you're dragging, the tabs scroll even faster! Just noting this stuff in case it helps with getting it all consistent.
(In reply to comment #5)
> Also, as noted elsewhere (I can't
> remember where), if you move the cursor around over the scroll arrow while
> you're dragging, the tabs scroll even faster!

I think it was bug 343597.

Comment on attachment 277512 [details] [diff] [review]
Patch

ui-r=me on the smooth scrolling when holding.
Attachment #277512 - Flags: ui-review?(mconnor) → ui-review+
Comment on attachment 277512 [details] [diff] [review]
Patch

Bug 357081 needs a new sync anyway thanks to bug 339964.
Attachment #277512 - Flags: review?(enndeakin)
Attachment #277512 - Flags: review?(enndeakin) → review+
Keywords: checkin-needed
Bug 357081 has changed this a little again, can you verify that the patch is still valid and attach a version that applies cleanly then I'll check it in.
Assignee: nobody → ventnor.bugzilla
Status: NEW → ASSIGNED
Attached patch Synced to trunkSplinter Review
Thanks.
Attachment #277512 - Attachment is obsolete: true
Checking in toolkit/content/widgets/scrollbox.xml;
/cvsroot/mozilla/toolkit/content/widgets/scrollbox.xml,v  <--  scrollbox.xml
new revision: 1.26; previous revision: 1.25
done
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
I think it's potentially irritating that scrollByIndex -- which is kicked off in _stopScroll -- can go faster than the constant scrolling. I have yet to actually notice this, but depending on a higher tabMinWidth (or with non-tabstrip scrollboxes) it could become a problem. Other than that, this works pretty well.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082605 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 3 M8
You need to log in before you can comment on or make changes to this bug.