If I grab a scrollbars "elevator", and drags it through a document or a webpage then it does not highlight. It should be highlighted all the time while the mouse is down. I believe this is a regression.

i see this on linux too: when i click, the elevator hightlights, but as soon as the drag starts, highlight vanish. Could be a "modern3" thing, in which case it should be dup'ed against bug 78221

Well, I only see it in modern, and I don't think it is intended behavior (hence not a dup of bug 78221) so I'll let the modern folks sort it out. ->hewitt

No, this is not a themes thing. This is XPToolkit. Testcase: 1. Click on a widget (choose whichever you like the most: button, toolbar-button, scrollbar, form-button etc.) and then drag the mouse outside of the widget - and mouse over it again. It should depress as soon as you enter it again with the cursor, right? It doesn't! This is throughout the app. This started happening just before the modern-landing, and it happens in all themes so it is certainly XPToolkit. Trudelle, get this reassigned ASAP - it's really major loss of functionality. Thanks

I would believe this is critical (or even a smoketest blocker for widget tests?) but I will let the QAs sort that out. CC'ing a bunch of folks to get attention, sorry if you are not related to this problem, feel free to un-cc. :)

Okay, some one was messing around with mousein/out behavior recently, this might be related.

not me!

i see this on mac classic in the 5/1 build. the thumb deselects without the mouse doing anything. i filed a bug which is probably a dupe.

The testcase above doesn't sound anything like the original description, but it does sound like a dup of several other bugs. This bug is about the original described problem, we aren't morphing it into 20 other problems. restoring original summary.

removing myself from the CC.. with a comment that hwaara, you changed have the summary from a perfectly good, specific bug ("scrollbars elevator doesn't highlight during drag") into a vague, unmeasurable, unverifiable bug ("focus on widgets is seriously messed up").. good job!

Trudelle, it's the same bug: click on widget, mouse out, mouse in again. note to alecf: so why did you change it back after trudelle's change?

Hwaraa, the difference is that, when dragging, you are not mousing out of the widget. I still see this on Linux today, but no longer on Mac.

Hmm. delta to drag before hilite goes seems to be about the same as minimal thumb size. coincidence?

->evaughan/future. re there any other Linux apps that hilite the thumb like this?

I strongly protest futuring this bug. Basic UI fucntionality and a regression no less.

NC4.* on IRIX 6.5: thumb highlights on mouseover - remains on during grab - vanishes when grab is relased AND mouse is not over thumb. (If cursor is still over thumb when grab is released, hightlighting is left on untill cursor moves away. This is also how native IRIX apps behave. NC4.* on Linux doesn't highlight thumb at any point, I believe. I agree this shouldn't be futured: Either the whole feature should be removed - or highlighting should behave in some logical manner. As it works right now it's clearly bugged and all too visible. Personally I'd prefer a fix - I liked the highlighting.

Okay, since this has once again regressed on Mac, where the highlighting is standard behavior, and also on Win32, I'll pull it back in and hope that we have time to deal with it. If not, we should consider fixing by removing the hightlight altogether, which is more correct behavior on Linux & Win9X anyway. ->0.9.2/P4/ALL/ALL

Interesting observation in bug 80027: When you grab the thumb with MIDDLE mouse button, hightlighting is "correct". I don't think it should highlight then at all, but is it possible this is all caused by mouse-buttons getting mixed up in scrollbar code somewhere?

*** Bug 80027 has been marked as a duplicate of this bug. ***

It should hightlight also when middle-button grabbing. Forget comment above.

> Hmm. delta to drag before hilite goes seems to be about the same as minimal > thumb size. coincidence? I'd guess so, yes, a coincidence based on how fast you normally drag. On the Mac at least (2001051109, Mac OS 9.1, Classic theme), delta to drag before highlight goes isn't measured in pixels -- it's measured in tenths of a second. FWIW, I vote for retaining the highlight, even though it's buggy. By the time the highlight disappears, the user will often not be looking at the scrollbar any more, so they may not even notice. I filed bug 80462 for the separate issue of widgets not regaining mousedown appearance. I *think* that other bug is also happening to scrollbar thumbs, but it's a bit hard to tell while this bug is also present.

*** This bug has been marked as a duplicate of 80462 ***

I don't think this is a dup. The highlight was lost even if I didn't move the mouse at all, just held it on the same pixel for 0.5 seconds. But I'll have to download a new build to be sure ...

Hmm, okay. I can't get my scrollbar to change shades at all, so it's hard to test.

MPT: I was trying to indicate that the highlight disappeared for me based only on distance moved, not time or speed, and that distance was about the size of the minimal thumb. I think that the distraction of a disappearing highlight more than makes up for any purported benefit, but don't really feel strongly either way. Looks like the highlight has been removed recently anyway.

on mac, at least, mpt is correct and that the hilight goes away after a set amount of time, regardless of distance. it appears that hilight has been removed from modern, but probably not from classic.

->0.9.3/helpwanted. Possible limbo candidate if an easy fix appears, but I wouldn't want my enginers spending any signficant time on it in this release cycle.

The highglight works perfectly now (build 2001062105, Mac OS 9.1), but only if you drag the topmost/bottommost (black) pixel of the vertical scrollbar thumb, or the leftmost/rightmost (black) pixel of the horizontal scrollbar thumb. The highglight doesn't happen if you drag any other part of the thumb. So, my guess is that the highlight was turned off incompletely when it wasn't working properly, but now it's working again, and it needs to be turned back on.

Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.

I think we can live without this for 0.9.4. let me know if this is not right.

pushing out

This worksforme in build 2001122008, Mac OS 9.1, Classic theme -- I guess it was fixed by Hewitt's Classic rewrite. It's still not fixed in Modern.

Ok, so everything works as it should except for Modern. (Mac Classic works, Windows Classic never did the highlight thing; so it works and Modern is still not working.)

Comment on attachment 62572 [details] [diff] [review] Fix modern r=andreww

Comment on attachment 62572 [details] [diff] [review] Fix modern sr=hewitt

Fix checked in.