Closed
Bug 333175
Opened 18 years ago
Closed 17 years ago
GrabMouseEvents not reset if a mouseup handler kills target frame
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
DUPLICATE
of bug 401528
People
(Reporter: jwatt, Unassigned)
Details
After a mouseup event has completed the bubble phase for the default event group we should stop capturing mouse events that occur outside the window. The stack for the GrabMouseEvents call should look like this: nsViewManager::GrabMouseEvents nsFrame::CaptureMouse nsFrame::HandleRelease nsFrame::HandleEvent nsPresShellEventCB::HandleEvent nsEventTargetChainItem::HandleEventTargetChain However, if an event handler in the default group removes the target of the mouseup event from the document then there's no frame for the nsFrame::HandleEvent call. As a result we continue to capture mouse events after mouseup. I'm not sure at this stage what the "correct" way to fix this is.
Updated•18 years ago
|
Flags: blocking1.9a1?
Reporter | ||
Comment 1•18 years ago
|
||
This bug is also present in the 1.8 branch, although the code is different.
Reporter | ||
Comment 2•18 years ago
|
||
And the HandleEvent of some nsFrame sub-classes check for nsEventStatus_eConsumeNoDefault and return if preventDefaut() was called before nsFrame::HandleEvent() can be called.
Flags: blocking1.9a1? → blocking1.9-
Reporter | ||
Comment 3•17 years ago
|
||
To provide more context, the stack would typically look like this (but gets cut off at nsPresShellEventCB::HandleEvent since no frame is found): nsFrame::CaptureMouse(nsPresContext *, int) nsFrame::HandleRelease(nsPresContext *, nsGUIEvent *, nsEventStatus *) nsFrame::HandleEvent(nsPresContext *, nsGUIEvent *, nsEventStatus *) nsPresShellEventCB::HandleEvent(nsEventChainPostVisitor &) nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor &, unsigned int, nsDispatchingCallback *) nsEventDispatcher::Dispatch(nsISupports *, nsPresContext *, nsEvent *, nsIDOMEvent *, nsEventStatus *, nsDispatchingCallback *) PresShell::HandleEventInternal(nsEvent *, nsIView *, nsEventStatus *) PresShell::HandlePositionedEvent(nsIView *, nsIFrame *, nsGUIEvent *, nsEventStatus *) PresShell::HandleEvent(nsIView *, nsGUIEvent *, nsEventStatus *) nsViewManager::HandleEvent(nsView *, nsPoint, nsGUIEvent *, int) nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *) HandleEvent(nsGUIEvent *) nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) nsWindow::DispatchWindowEvent(nsGUIEvent *) nsWindow::DispatchMouseEvent(unsigned int, unsigned int, long, int, short) ChildWindow::DispatchMouseEvent(unsigned int, unsigned int, long, int, short) nsWindow::ProcessMessage(unsigned int, unsigned int, long, long *)
Reporter | ||
Comment 4•17 years ago
|
||
I was thinking that if nsPresShellEventCB::HandleEvent can't find a frame, then it should check for a mouseup event and then find the root view manager and tell it to stop grabbing mouse events. That doesn't address comment 2 though.
Comment 5•17 years ago
|
||
This should be fixed in bug 401528. Please reopen if there is something different here...
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Updated•5 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
•