In apprunner, we're using multiple frames (more or less) to embed a content area in our window (which itself is a content area). This generates multiple pres shells, once for each. The problem is that nsEventStateManager is tied to a presShell, so you miss mouse enter/exit events that cross between different pres shells. Here's an example of what happens today: - put the mouse in the area where a webpage goes. Events here go to presShell A. - now move the mouse up to a toolbar. The mouseMoved event code notices that something moved and passes the event into gecko. The view system handles the event and passes it to the presShell which calls upon the nsEventSTateManager do generate mouse enter/exit events. Ok, this one might be ok because the mLastMouseOverFrame member is null (you haven't had the mouse here yet). Events here go to presShell B. - Move the mouse back down into the web content area. Again the mouse move event goes into gecko -> view -> presShell. But since we're back in presShell A, when the eventStateManager looks to see what the last frame was, lo and behold, it's the web content area. since each presShell has its own copy of the eventStateManager, it doesn't know that the mouse ever left this presShell (mLastMouseOverFrame is the webcontent frame). No mouseEnter/exit events are generated - Move the mouse back to the bottom toolbar. AGain, presShell B talks to the eventStateManager and, as far as it knows, the bottom toolbar was the last frame hit, so no mouse enter/exit events. - If you move the mouse to the top toolbar, you get the mouse enter/exit events because the eventStateManager in presShell B can tell that you moved w/in frames in the same presShell. All is good in this case. This has some pretty serious implications on drag and drop mouse enter/leave.

This "works" on mac right now (the toolbox will get enter/exit events) on macos because the macOS nsEventManager is duplicating the work that the nsEventStateManager should be doing, only getting it right ;) If it didn't do that, i'd have noticed this a long time age.

I'm not sure the Mac Widgets do anything special: on Windows and Unix too, the mouse enter/exit events are propagated (look in nsWindow::DispatchMouseEvent() in widget/src/windows/nsWindow.cpp).

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

Mass-moving bugs out of M15 that I won't get to. Will refit individual milestones after moving them.

Bulk prioritizing bugs for correct milestones.

Adding [STATE] keyword to bugs dealing with bad internal state created by lost or overridden events.

I tested this on today's Mac builds and the scrollbar no longer steals the focus away from the input text field. Marking worksforme...

Mass update: changing qacontact to ckritzer@netscape.com

Updating QA Contact.

Relying on Nisheeth's quick summary of a problem caused by this bug (text field losing focus if scroll bar is clicked on), marking VERIFIED on Mac 01-19-12.