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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is going to take some script breakdown. Marking future till I (or someone else) has more time to break it down.
Target Milestone: --- → Future
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.
Created attachment 66026 [details] 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).
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.
Created attachment 69849 [details] 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.
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.
err, s/large number of mouseovers/large number of mousemoves/, sorry. :-)
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.