GrabMouseEvents not reset if a mouseup handler kills target frame

RESOLVED DUPLICATE of bug 401528

Status

()

Core
Event Handling
RESOLVED DUPLICATE of bug 401528
12 years ago
10 years ago

People

(Reporter: jwatt, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

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?
(Reporter)

Comment 1

12 years ago
This bug is also present in the 1.8 branch, although the code is different.
(Reporter)

Comment 2

12 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

11 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

11 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.
This should be fixed in bug 401528.
Please reopen if there is something different here...
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 401528
You need to log in before you can comment on or make changes to this bug.