178519 - Mousemove events do not work when position is not static

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P3)

Description

[Erik Arvidsson]

This case is a bit tricky. It took me about a day to figure out what was going
on and create a simplified test case.

This bug is preventing us from implementing movable toolbars.

Now to the bug description:

Desired behavior: The user press down the mouse button, moves the mouse and
releases the mouse button. During the move a mouse move listeners checks the
mouse position and updates the size, position and the location of an element in
the DOM tree (removeChild/appendChild/insertBefore). The user will in most cases
move the mouse outside the actual browser window (the chrome area) since
toolbars are located near the edge and to position the toolbar outermost the
user moves the mouse outside that edge.

Actual behavior: When an element has position set to anything but "static" and
the location of the element in the DOM tree is changed (using
removeChild/appendChild/insertBefore) the mousemove events are no longer fired
when outside the document (over iframes or outside the chrome).

If the location in the DOM tree is kept or the position is set to static the
events are fired correctly.

Comment 1

[Erik Arvidsson]

Attachment: Shows that mousemove does not work when position not set to static

Drag the element with the "Drag me" text. Note that the status bar is update
even when outside the browser window.

Now change the postion to something except static (by selecting a radio
button). Note that no events are triggered outside the window while dragging
the element.

Comment 2

[Vladimir Ermakov]

This is interesting.. Why would dragging staticly positioned element be
different then dragging a relatively, or absolutely positioned one?..  Related
to 74348, and 185919.

Comment 3

[Boris Zbarsky [:bzbarsky]]

because positioned elements get views, perhaps?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

taking

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

The whole idea of keeping a capture going while your element is not even in the
document is a bit weird, but this fixes the testcase and is probably "good
enough".

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 112635 [details] [diff] [review]
fix

simple patch

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 112635 [details] [diff] [review]
fix

>+  void DropMouseGrabbing();

Maybe RelinquishMouse() ?  If not, I guess DropMouseGrabbing is ok...

>+  nsView* grabbingView = mViewManager->GetMouseEventGrabber();
>+  if (grabbingView == this) {

if (this == mViewManager->GetMouseEventGrabber()) {

>+  DropMouseGrabbing();
>+  
>   if (nsnull != mViewManager)

As long as you're here, |if (mViewManager)|.

Comment 8

[Kevin McCluskey (gone)]

Comment on attachment 112635 [details] [diff] [review]
fix

r=[e-mail]

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked in.