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

VERIFIED WORKSFORME

Status

()

P3
major
VERIFIED WORKSFORME
20 years ago
18 years ago

People

(Reporter: mikepinkerton, Assigned: joki)

Tracking

Trunk
All
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
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.
(Reporter)

Comment 1

20 years ago
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

20 years ago
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

20 years ago
*** Bug 9456 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Target Milestone: M15
(Assignee)

Comment 4

19 years ago
Mass-moving bugs out of M15 that I won't get to.  Will refit individual 
milestones after moving them.
Target Milestone: M15 → M16
(Assignee)

Comment 5

19 years ago
Bulk prioritizing bugs for correct milestones.
Target Milestone: M16 → M18
(Assignee)

Comment 6

19 years ago
Adding [STATE] keyword to bugs dealing with bad internal state created by lost 
or overridden events.
Status: NEW → ASSIGNED
Summary: mouse enter/exit events not correct across pres shells → [STATE] mouse enter/exit events not correct across pres shells

Comment 7

19 years ago
I tested this on today's Mac builds and the scrollbar no longer steals the focus 
away from the input text field.  Marking worksforme...
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 8

19 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 9

18 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca

Comment 10

18 years ago
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.