Closed Bug 178519 Opened 22 years ago Closed 22 years ago

Mousemove events do not work when position is not static

Categories

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

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: erik, Assigned: roc)

Details

(Keywords: testcase, Whiteboard: [fix])

Attachments

(2 files)

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.
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.
This is interesting.. Why would dragging staticly positioned element be different then dragging a relatively, or absolutely positioned one?.. Related to 74348, and 185919.
Keywords: testcase
Priority: -- → P3
because positioned elements get views, perhaps?
taking
Assignee: joki → roc+moz
Attached patch fixSplinter Review
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 on attachment 112635 [details] [diff] [review] fix simple patch
Attachment #112635 - Flags: superreview?(bzbarsky)
Attachment #112635 - Flags: review?(kmcclusk)
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)|.
Attachment #112635 - Flags: superreview?(bzbarsky) → superreview+
Attachment #112635 - Flags: review?(kmcclusk) → review+
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: