Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Mousemove events do not work when position is not static

RESOLVED FIXED

Status

()

Core
DOM: Events
P3
blocker
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Erik Arvidsson, Assigned: roc)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fix])

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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

15 years ago
Created attachment 105227 [details]
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

15 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

15 years ago
because positioned elements get views, perhaps?
taking
Assignee: joki → roc+moz
Created attachment 112635 [details] [diff] [review]
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 on attachment 112635 [details] [diff] [review]
fix

simple patch
Attachment #112635 - Flags: superreview?(bzbarsky)
Attachment #112635 - Flags: review?(kmcclusk)
Whiteboard: [fix]

Comment 7

15 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 on attachment 112635 [details] [diff] [review]
fix

r=kmcclusk@netscape.com
Attachment #112635 - Flags: review?(kmcclusk) → review+
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.