Closed
Bug 5519
Opened 26 years ago
Closed 25 years ago
[STATE] mouse enter/exit events not correct across pres shells
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M18
People
(Reporter: mikepinkerton, Assigned: joki)
Details
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•26 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•26 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).
Assignee | ||
Updated•25 years ago
|
Target Milestone: M15
Assignee | ||
Comment 4•25 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•25 years ago
|
||
Bulk prioritizing bugs for correct milestones.
Target Milestone: M16 → M18
Assignee | ||
Comment 6•25 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•25 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
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 8•25 years ago
|
||
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Comment 10•24 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
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•