84092 - onmouseup events not being handled

Status: RESOLVED INVALID

(Core :: DOM: Events, defect)

Description

[brian donovan]

Click on the Greenish-yellow rectangle and drag it around.  Release your mouse 
button.  Without clicking anywhere else in the window, click on the rectangle 
again and attempt to drag.  The problem will be evident.  Apologies for the 
less than exhaustive description (feel free to add more info).

This same problem can be seen on a page with an earlier version of the script 
and more draggables (before browser checking was added):
http://test.monokromatik.com/index18.htm

Comment 1

[Vladimir Ermakov]

First time you move a blue box everything is fine. But if you try to move it  
second time in a row you will see that mosedown is not enough to make it move. 
You need to click then it will move with the mouse and when you click again it 
gets "droped". If you click a different box every time though, it moves like it 
should.

Comment 2

[joki (gone)]

This is going to take some script breakdown.  Marking future till I (or someone 
else) has more time to break it down.

Comment 3

[brian donovan]

I understand that there are are plenty of bugs to squash (too many for them all 
to possibly be fixed in time) and that some are more important than others, so 
I'm not surprised that this bug has been futured.  Still, I'd like to make the 
point that this bug is of the variety that will tend to seriously affect 
adoption of mozilla by many developers.  
.
.
.
A fair number of dhtml gui widgets incorporate dragging behavior.  The behavior 
described in my initial post is manifested in all of the drag n' drop scripts 
that I've played with (after seeing that mine wasn't working and filing this 
report, I tried some other people's scripts). Developers/designers tend to be 
early adopters and, to some extent, play a role in the overall penetration of 
browsers, plugins, etc.  After spending the time to write or rewrite scripts 
that incorporate dragging so that they'll work in mozilla/NS6, they'll discover 
this bug and frustration will result.  They may even resort to redirecting 
mozilla/ns6 users away/out of their sites.  I'm sure that you see where I'm 
going with this.
.
.
.
I apologize for taking up space here with these comments.  Thanks for your 
patience.

Comment 4

[Christian Schmidt]

Attachment: Simple test case

Appearently the odd behaviour is triggered by a missing ALT attribute in the
IMG tag.

This attachment is a test case based on the page mentioned by the reporter. It
contains two images. The upper image is missing the ALT attribute.

The lower image can be dragged just fine. But the upper image suffers from the
problem reported in this bug: when being dragged the second time, the picture
only moves a little bit and then the cursor changes into the Ø-symbol (the icon
used when dragging something that cannot be dropped at the current position).

Comment 5

[Christian Schmidt]

Between build 2002020208 and build 2002020409 (both Win2K) something changed:

On http://test.monokromatik.com/readyJune01/indexdrag3.htm dragging the bright
box now works even worse. However, after having read comment 8 in bug 114852 I
don't think it is supposed to work. In order to make the script work,
|event.preventDefault()| should be called from the mousedown event handler. This
should make the script in the test URL work.

After the change, the two pictures in attachment 66026 [details] now behave in the same
way, i.e. the absence of an ALT attribute does no longer seem to make a difference.

Comment 6

[Christian Schmidt]

Attachment: Testcase #2

This attachment is a new testcase. The mousedown event handler for the upper
picture calls |event.preventDefault()|, the event handler for the lower picture
does not. Upon mousedown, mouseup and mousemove the event name is written to
the window status bar. 

Dragging the upper picture around works fine - according to the window status
bar, mousedown, mousemove and mouseup are triggered as expected.

Dragging the lower picture turns the cursor into an Ø-symbol, and the picture
only moves a little bit. But when the mouse button is released, the picture
moves to the cursor position. According to the window status bar, the mouseup
event handler has not been triggered (hence the picture now follows the mouse
until a button is pressed). Is this behaviour right? IE6 does the same. The
question can be refrased to: Should mousedown and mouseup events always come in
pairs? If not, then I think this bug should be marked invalid.

Comment 7

[Bob Clary [:bc] (inactive)]

If you move the mouse very slowly, then the mousedown, drag, mouseup seems to
work fine on either image. 

However, if you move the mouse too fast, it appears that the events are being
lost on either image due to a large number of mousemove events happening too
quickly to be processed. 

If the mouse pointer turns to the Ø, then it appears that the event queue has
filled up and some of the events are dropped on the floor, notably the mouseup
event. 

IE suffers from the same problem.  

This is probably a combination of the large number of mouseovers occuring and
the relatively long time it takes to update the image position meaning that each
mousemove event handler is taking too long to complete given the number of
mousemoves/sec.

A possible code work around would be to call preventBubble in the mousemove
handler to keep the mousemove event from bubbling up through all of the elements
in the page and to only update the position of the image when a sufficient time
delay or change in position has occured. You might want to make the code that
updates the image position into a separate function, and call it via setTimeout.
Be sure to keep the actual time spent in the mousemove handler to an absolute
minimum.

I would say this is not necessarily a bug since you can not expect the image
position to be updated in real time as the mouse moves.

Comment 8

[Bob Clary [:bc] (inactive)]

err, s/large number of mouseovers/large number of mousemoves/, sorry. :-)

Comment 9

[Vladimir Ermakov]

I think this is invalid. If there is two event handlers they should both be
envoked unless one is suppressed. This is what is happening here, if you drag
the image it first calls the javascript handlers and then calls the default
handler for dragdrop, and we see the image starting to move a little and then
its starts being dragged by the default handler.