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)

defect
Not set
normal

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.
Flags: blocking1.9a1?
This bug is also present in the 1.8 branch, although the code is different.
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-
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 *)
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.
This should be fixed in bug 401528.
Please reopen if there is something different here...
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.