When scrolling tabs (by holding down the scroll buttons), often it's difficult to tell when you've reached the end of the scroll bar (if you have a lot of similar tabs open, for instance). Once we reach the end of the tab bar, the scroll button in question should be disabled so the user can see that they're at the end. STR: 1. Open at least a window and a half worth of tabs and scroll all the way to one side 2. Hold down the scroll button of the opposite side to that you're scrolled to 3. Keep holding... 4. Wonder if you're at the end yet What happens: Even though you're at the end of the tabs, the button still has the mousedown appearance What should happen: Button should get disabled appearance "Real" scroll buttons don't behave this way, so filing UNCO, but "real" scroll buttons also have scroll bars, which we don't.
I thought we had discussed this and decided we did want to to what Ian wants, or did I miss something?
Uhm, it gets disabled just fine once the mouse button is released, at least in last night's trunk nightly...
Once the mouse button is released. I'm talking about before the mouse button is released. On real scroll bars, you know you're not scrolling anymore because the scroll bar is all the way to one side (and the content stops moving). It's possible that bug 355491 will be sufficient, but I think the more visual feedback here the better.
Confirming as polish.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Camino1.2
Setting priority per 1.6 roadmap.
Priority: -- → P1
Since this is P1/UI, it should probably be blocking 1.6a1, although its severity is set to minor.
Summary: When scrolling tabs, buttons should be disabled once the end of the bar is reached → When scrolling tabs, buttons should be disabled once the end of the bar is reached (before mouse up)
The bad news is that when I looked at this before it looked like it was going to be a huge PITA to fix (requiring doing the mouse tracking entirely ourselves, rather than just using a repeating action on a stock button). The good news is, Leopard appears to have the correct behavior for repeating buttons that disable themselves, since this bug is WFM on Leopard. I think we should consider just letting this be something that's better on Leopard; the benefit/work ratio to fix this for 10.3 and 10.4 doesn't seem high enough given how minor an issue it is.
I think I'm OK with comment 7, since it's more-or-less what we've traditionally done with "OS bugs".
Closing WONTFIX (as a 10.3/10.4 bug) then; I don't think this is the sort of thing that will attract dupes, so no need to leave it open as we do with more serious OS bugs (if that turns out not to be true, we can reopen and Future it).
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Priority: P1 → --
Resolution: --- → WONTFIX
Summary: When scrolling tabs, buttons should be disabled once the end of the bar is reached (before mouse up) → [10.3, 10.4] When scrolling tabs, buttons should be disabled once the end of the bar is reached (before mouse up)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.