5519 - [STATE] mouse enter/exit events not correct across pres shells

Status: VERIFIED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

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.

Comment 1

[Mike Pinkerton (not reading bugmail)]

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.

Comment 2

[Pierre Saslawsky]

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).

Comment 3

[White-Gandalf]

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

Comment 4

[joki (gone)]

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

Comment 5

[joki (gone)]

Bulk prioritizing bugs for correct milestones.

Comment 6

[joki (gone)]

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

Comment 7

[Nisheeth Ranjan]

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

Comment 8

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 9

[Loco]

Updating QA Contact.

Comment 10

[Loco]

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.