355102 - Opening sidebar in Cocoafox eats hover state

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Phil Ringnalda (:philor)]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20061001 Firefox/3.0a1 ID:2006100120

Opening the Bookmarks or History sidebar in Cocoafox takes away hover state, until you click something, anything.

STR:

1. Open either default sidebar (or an extension sidebar like LiveHTTPHeaders, or a bookmark opened in the sidebar, so it's not just the way the defaults focus a text input)
2. Hover the sidebar close button, notice no change in image and no tooltip; hover a link in the main window, notice no URL in the statusbar; hover the Home toolbarbutton, notice no change in appearance and wonder if it's all bad.
3. Click anywhere, in the sidebar, in the main content window, or on a toolbar, and notice that hover status is back.

Comment 1

[Josh Aas]

Attachment: fix v1.0

This should fix a few hover-related bugs.

In this patch we stop getting mouseEntered: and mouseExited: events from cocoa views altogether. The reliability of those in terms of ordering and getting them at all is a problem. Turns out it is much more reliable and simpler to just use mouseMoved:. We lower our dependency on OS event ordering and reliability and the new algorithm recovers on every mouseMoved: event if we get into a bad state.

Comment 2

[Stan Shebs]

Comment on attachment 260781 [details] [diff] [review]
fix v1.0

The two spots in mouseMoved that now send mouse exited events should have comments saying why they're doing it - "to make enter/exit pair up properly" or some such. Other than that, the code looks fine to me.

Comment 3

[Josh Aas]

Attachment: fix v1.1

This includes a bug fix that I noticed before checking in v1.0. We would continually send NS_MOUSE_EXIT events to the last view entered when moving the mouse outside of a window.

This also has better comments.

Comment 4

[Josh Aas]

landed on trunk