43258 - [STATE] mousemove listening prevents mouseup on drag event

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Dylan Schiemann]

Overview Description: The goal here is to capture a drag event on a node.  
Upon capture of a mousedown, turning on a listener for mousemove prevents the 
mouseup event from being reported if the mouse is moved.
Steps to Reproduce: 
1) Use attached testcase.  Click on the link which turns on event listening of 
mousedown and mouseup for that node. 
2) Then try to drag inside that node (mousedown and mousemove).  Release of the 
button shows the mouseup event was never fired to cancel the listener for 
mousemove.
3) A quick click on the link will cancel the mousemove as long as the moise is 
not moved.

Actual Results: mouseup event not heard by listener if mousemove event is 
listened for with mousedown.

Expected Results: mouseup event is fired upon lifting up the mouse button 
regardless of mousemove event capture.

Reproducibility: Every time using testcase

Build Date & Platform Bug Found: Win2000 20000613

Additional Builds and Platforms Tested On: None

Additional Information: This is needed to capture simple drag events.

Comment 1

[Dylan Schiemann]

Attachment: test case

Comment 2

[Dylan Schiemann]

Attachment: testcase (without a script error)

Comment 3

[Matthew Cline]

Confirmed on Linux build 2000062020; someone should mark this "OS: All".

Also, I note that the mouseup event is fired if you don't do any dragging
after you mousedown, but if you do any dragging, then no mouseup.

Comment 4

[joki (gone)]

I'm cc'ing [e-mail] for his input.

So the reason for this bug is that once you move the mouse you start a system 
level drag session.  At this point you don't get mouseup any more.

I see two ways to solve this.  One, we make the beginning of the drag session 
preventable.  You would still not get a mouseup in this case but if you 
cancelled the initial mousedown you would get normal events.  Two, we translate 
the drag events and continue to deliver the normal events that people expect.  
The second one is harder.

Comment 5

[joki (gone)]

Adding [STATE] keyword to bugs dealing with bad internal state created by lost 
or overridden events.

Comment 6

[Jeffrey Baker]

Changing OS by request.

Comment 7

[Mike Pinkerton (not reading bugmail)]

why aren't you just listening for the drag gesture event? why are you trying to 
capture/track this yourself?

Comment 8

[Dylan Schiemann]

What drag gesture event are you referring?  There is no drag event specified in 
the DOM 2 specification as far as I know.

Comment 9

[Mike Pinkerton (not reading bugmail)]

are you in chrome/xul or are you trying to do html?

Comment 10

[Dylan Schiemann]

Event capture for standard html pages is what I was using.

Comment 11

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 12

[Bob Kanefsky]

I was about to report this very same bug when I found this report.  I'm trying to 

do the same thing, and I had a page that works great in M15 and is broken in 

2000072520 (tested under MacOs 9, so Platform should probably be All):

http://www.roving-mouse.com/planetary/sizes.html



In my own reduced test case, which I will attach, here's the M15 behavior if you 

drag from the red ball to the blue ball:



Mouse Over red ball

[Here's where I started the drag]

Mouse Down red ball

[I moved the mouse over the blue ball]

Mouse Out red ball

Mouse Over blue ball

[Here's where I dropped]

Mouse Up blue ball

... when mouse finally moved off page:  Mouse Out blue ball



Here's the M17 behavior:



Mouse Over red ball

[Here's where I started the drag]

Mouse Down red ball

[I moved the mouse over the blue ball -- nothing]

[Here's where I dropped, and suddenly]

Mouse Out red ball

Mouse Up blue ball

Mouse Out red ball

Mouse Over blue ball

[and then it put the URL of the ball in the URL field and spun the barberpole]

... when mouse finally moved off page:  Mouse Out blue ball



Note that my test case does not listen for MouseMove.



In M15, the images behave consistently with the text in my test case (which has 

no links).  In 2000072520, they do not.  The behavior for text has not changed; 

in both builds the text behaves this way:



Mouse Over red text

Mouse Down red text

Mouse Out red text

Mouse Over blue text

Mouse Up blue text

Mouse Out blue text



I second the question "What's a drag gesture event"?  I don't see anything like 

it in the JavaScript client documentation, except for onDragDrop, which seems to 

be intended for objects dragged from outside the page.  Is that some new XUL 

thing?  For my part, I had everything working with DOM(1?) and CSS(1?) under M15 

(built on earlier sample code from dmoz's DOM category), and now I can't figure 

out how to make my real page's drag-and-drop work under M17.

Comment 13

[Bob Kanefsky]

Attachment: Kanef's test case

Comment 14

[Bob Kanefsky]

I have some more observations and speculation to add, now that I've rerun my test 

case after restarting 2000072520.  Some of the behavior had been obscured due to 

an unrelated problem that made it stop visiting any pages at all.  It's now clear 

what it's doing, I think:



Observations:  (1) Dragging an image in test case makes a transparent image 

appear, as though it's being handled by the native MacOS9 drag-and-drop 

functionality.  (2) Dropping it causes the image to be opened as a document.  (3) 

This is exactly what happens when an inlne image is dragged to a different 

window, or when a document is dragged from the desktop to a browser window.  (I'm 

guessing this also applies to links as well as inline images.)



Speculation:  It's now pretty clear that rather than existing code having a new 

bug, some new drag-and-drop feature is interfering with the DOM1 events that I 

for one was using to implement my own drag-and-drop (following a previous 

published example).



I don't know whether the new behavior is DOM1-compliant or not, but it's not 

compatible with pages designed to work under M15 or Netscape's first preview 

release.  Is there at least a way for content developers to disable it on our 

pages?  For my part, I'd like mine to work as it did before without my having to 

rewrite it, but I'd consider using a more elegant drag&drop interface if one is 

available and working and is already a W3C recommendation.

Comment 15

[Bob Kanefsky]

To clarify desired behavior, here's another test to try with my same test case 

attachment:  Drag the red ball through the blue ball and into another browser 

window (i.e., point at red ball, press and hold mouse button, move over blue 

ball, move over another window, release button).



Actual behavior:

Mouse Over red ball

Mouse Down red ball

Mouse Out red ball

Second window visits red ball document.

[and the last event is repeated when the mouse is again moved over the window 

containing the test case].



Desired behavior:

Mouse Over red ball

Mouse Down red ball

Mouse Out red ball

Mouse Over blue ball

Mouse Out blue ball

and then go ahead and open it in the other window if you must.



It's tangential to the MouseUp issue and less practical, but is probably a 

manifestation of the same bug/misfeature and makes a cleaner-cut demonstration.



Unless mine is a different bug from the original, the Summary could be 

generalized to "Drag&drop functionality is inhibiting DOM1 mouse events while 

button is down".  It can happen with no mousemove, no listener, and no onMouseUp.

Comment 16

[Bob Kanefsky]

Also broken:  http://www.mozilla.org/docs/dom/samples/resize/
In M15, it resizes.  In M17 (2000072520), it moves.

Comment 17

[Dylan Schiemann]

I believe that your bug is different than this one as images and links are 
being inhibited by a higher level drag-drop interface.  I changed my testcase 
to use a pragraph element... no inhibition from higher level drag drop, but 
still the dragging prevents the mouseup event from being heard. My example does 
not work in M15 either, so it is likely different.  New testcase for paragraph 
to follow.

Comment 18

[Dylan Schiemann]

Attachment: testcase with paragraph element instead of anchor

Comment 19

[Bob Kanefsky]

OK, I guess I erred too much on the side of avoiding possible duplication.  I've 
opened a new report, Bug 47022, to track my bug.  I've copied the attachment and 
re-summarized my description, as amended.

Comment 20

[Mike Pinkerton (not reading bugmail)]

forget I said anything about dragGesture, I thought you were trying to do d&d in 
the chrome. My bad.

I need to mull this over, probably with saari and joki but later...

Comment 21

[Joe Hewitt]

I ran into this problem in XUL and solved it like this:

this.addEventListener("draggesture", function(aEvent) { aEvent.cancelBubble =
true; }, false);

Under IE5, the same exact thing happens and is solved in exactly the same way on
an HTML page (with IE's proprietary DND events).  So does Mozilla recognize
draggesture on HTML elements?

Comment 22

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Nominating for nsbeta3. Mouse events are quite broken currently. Bug 47022 is 
somewhat related and it is nsbeta3+.

Comment 23

[Nisheeth Ranjan]

Marking nsbeta3+...

Comment 24

[Mike Pinkerton (not reading bugmail)]

not sure what to say here....ummmm....doh?

Comment 25

[Mike Pinkerton (not reading bugmail)]

joki and i talked this over and we think the best thing to do is to keep the 
behavior we had in 4.x, ie, if you don't want the browser starting a drag and 
leaving you in the lurch, you need to return false from your onMouseDown event 
handler. 

I'll make the change in the ESM to not set the dragGesture state machine in 
motion if i see that the event handler of the mouseDown returns false. Taking 
this bug.

Comment 26

[Mike Pinkerton (not reading bugmail)]

fixed.

note that you have to put a "event.preventDefault()" or "return false" at the end 
of the mouseDown handler. doing so disables selection, is that ok?

Comment 27

[Dylan Schiemann]

Just to clarify, returning false from the onmousedown handler allows you to 
then detect mousemove and mouseup events on a drag instead of a drag event?  If 
so, then this is exactly what is needed.

Comment 28

[Mike Pinkerton (not reading bugmail)]

ah-yup.

Comment 29

[Mike Pinkerton (not reading bugmail)]

i may have to back out my fix for this, my fix broke dragging links. anyone care 
to share why clicking a link returns consume_noDefault from the mouseDown event?

Comment 30

[Mike Pinkerton (not reading bugmail)]

i have a fix for the link dragging (52541), and made sure that it didn't regress 
this bug. all is once again good and kind in the world.

Comment 31

[Loco]

Updating QA Contact.

Comment 32

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 33

[Dylan Schiemann]

Marking VERIFIED as revised testcase with addition of return false for 
onmousedown event handler functions as expected.  Attachment of testcase 
showing this to follow.

Comment 34

[Dylan Schiemann]

Attachment: testcase showing fixed