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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: erik, Assigned: roc)
Details
(Keywords: testcase, Whiteboard: [fix])
Attachments
(2 files)
2.54 KB,
text/html
|
Details | |
2.55 KB,
patch
|
kmcclusk
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•22 years ago
|
||
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•22 years ago
|
||
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
![]() |
||
Comment 3•22 years ago
|
||
because positioned elements get views, perhaps?
Assignee | ||
Comment 5•22 years ago
|
||
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".
Assignee | ||
Comment 6•22 years ago
|
||
Comment on attachment 112635 [details] [diff] [review]
fix
simple patch
Attachment #112635 -
Flags: superreview?(bzbarsky)
Attachment #112635 -
Flags: review?(kmcclusk)
Assignee | ||
Updated•22 years ago
|
Whiteboard: [fix]
![]() |
||
Comment 7•22 years ago
|
||
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+
Comment 8•22 years ago
|
||
Attachment #112635 -
Flags: review?(kmcclusk) → review+
Assignee | ||
Comment 9•22 years ago
|
||
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.
Description
•