Closed Bug 613781 Opened 11 years ago Closed 11 years ago

Window buttons (close, minimize, maximize) appear hovered although they are not when resizing window


(Core :: Widget: Win32, defect)

Windows 7
Not set



Tracking Status
blocking2.0 --- final+


(Reporter: jonathan_haas, Assigned: jimm)



(Keywords: regression)


(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101120 Firefox/4.0b8pre
Build Identifier: 

The custom minimize/maximize/close buttons, we use when aero glass is disabled, can appear hovered when they are not.

Reproducible: Always

Steps to Reproduce:
Disable aero glass if available, I reproduced this under areo basic, but i guess it should be reproduceable with XP/Luna, too.

1. Unmaximize window if maximized
2. Disable menubar if visible to enable firefox button and custom title drawing
3. Make the window rather small so there is enough space to grow it
4. Position the mouse on the close button
5. Move the mouse slightly to the right so it is on the resizing border
6. Drag the window larger, moving the mouse slowly to the right
Actual Results:  
The titlebar buttons appear hovered one after another. First the close button, then the maximize button and then the minimize button. Firefox seems to remember the mouse position where it was before dragging or leaving the close button instead updating the mouse position when making the window larger.

Expected Results:  
Buttons shouldn't appear hovered
Blocks: 513162
Keywords: regression
Version: unspecified → Trunk
I am unable to reproduce this after following your steps.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101120 Firefox/4.0b8pre
confirmed. This isn't specific to the caption buttons, I can reproduce this in the favorites bar with the bookmarks button.

Requesting blocking so I can keep track of this. I'd like to figure out what's going on here.
Assignee: nobody → jmathies
blocking2.0: --- → ?
Ever confirmed: true
No longer blocks: 513162
blocking2.0: ? → final+
Blocks: 513162
Attached patch patchSplinter Review
This patch tracks mouse enter/exit more reliably and insures we always get a mouse exit event.

This problem regressed when we removed child widgets from the main view. Windows apparently doesn't send WM_MOUSELEAVE until the mouse leaves the window vs. the client area when TrackMouseEvent isn't in use. (Seems like they've depreciated the original meaning of this event somewhat.) This patch relies on WM_NCMOUSEMOVE as a trigger for sending the event when the mouse leaves the client area.
Attachment #494430 - Flags: review?(tellrob)
Comment on attachment 494430 [details] [diff] [review]

Seems to have fixed it!
Attachment #494430 - Flags: review?(tellrob) → review+

Thanks Rob!
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.