[10.3, 10.4] When scrolling tabs, buttons should be disabled once the end of the bar is reached (before mouse up)

VERIFIED WONTFIX

Status

--
minor
VERIFIED WONTFIX
12 years ago
11 years ago

People

(Reporter: froodian, Unassigned)

Tracking

({polish})

Trunk
Camino1.6
PowerPC
Mac OS X
polish

Details

(Reporter)

Description

12 years ago
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?

Comment 2

12 years ago
Uhm, it gets disabled just fine once the mouse button is released, at least in last night's trunk nightly...
(Reporter)

Comment 3

12 years ago
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.
(Reporter)

Comment 4

12 years ago
Confirming as polish.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: polish
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.
Flags: camino1.6a1?
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)

Comment 7

11 years ago
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".

Comment 9

11 years ago
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
Flags: camino1.6a1?
You need to log in before you can comment on or make changes to this bug.