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

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Jonathan Haas]

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

Comment 1

[Josh Tumath]

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

Comment 2

[Jim Mathies [:jimm]]

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.

Comment 3

[Jim Mathies [:jimm]]

Attachment: patch

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.

Comment 4

[Rob Arnold [:robarnold]]

Comment on attachment 494430 [details] [diff] [review]
patch

Seems to have fixed it!

Comment 5

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/075f5eb9a70b

Thanks Rob!