Scrollbar thumb is not invalidated when it goes out of :hover

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
17 years ago
11 years ago

People

(Reporter: bryner, Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
As hyatt and I discussed, the scrollbar thumb can get "stuck" in a hover state
when you move the pointer from the thumb into the page content area.  It does
not seem to happen when you move the pointer from the thumb into the scrollbar
track, which suggests the problem happens when the pointer crosses a widget
boundary.  The problem is visible on winxp and on Linux if you use the classic
theme with nsITheme support enabled.
(Reporter)

Comment 1

17 years ago
Chris, any ideas on this one?  This should be happening via
nsEventStateManager::SetContentState(), right?
(Reporter)

Comment 2

17 years ago
Ok, I tracked this down.  The problem is that the repaint is being "optimized"
to a repaint on the parent content (the scrollbar track) when the pointer is
moved from the thumb onto the track.  Both Linux and Windows'
WidgetStateChanged() method on the NativeTheme class is returning false for
aShouldRepaint for the scrollbar track, so no repaint is happening.

Reassigning to hyatt to fix the win32 WidgetStateChanged() method.
Assignee: joki → hyatt
Component: Event Handling → Themes
OS: All → Windows XP
Hardware: All → PC

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Assignee)

Updated

11 years ago
Product: Core → SeaMonkey
Assignee: hyatt → nobody
Status: ASSIGNED → NEW
QA Contact: madhur → themes
Target Milestone: Future → ---

Comment 3

11 years ago
Cannot reproduce this old bug.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.