114852 - Dragging an img-element does not always work

Status: VERIFIED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[José Jeria]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+)
Gecko/20011211
BuildID:    20011211

I made a drag and drop for an image, and it does not always work. This is really
driving me crazy. Dont see any errors in the code and I am starting to believe
that this i a bug. This does not happend with other elements, only img.

Reproducible: Always
Steps to Reproduce:
1. run testcase
2. drag the image around. release it.
3. repeat step 2 several times until you see that the img is not dragged

Actual Results:  Sometimes you cannot drag the image. The cursor changes to "ø".
Mouseover the image again to be able to continue the drag. 

Expected Results:  The image should always be dragged and follow the mouse cursor.

Comment 1

[José Jeria]

Attachment: This is an image needed for the testcase to work

Comment 2

[José Jeria]

Attachment: Try this

As mentioned, this only happends with an img. Try dragging it at least 10 times
to see what I mean.

Comment 3

[djk]

I think I see this with build 2001121103 w98.

For me, when the 'drag' cursor is "ø", I release the mouse button and *then* the
image snaps to and follows the cursor around until I click again.

Seems like the onmousedown and onmouseup events are a little messed up...

Comment 4

[Marc Boullet]

This is funny, because I was on the point to report
the same type of bug. Actually, I don't know the
exact meaning of the "NO PARKING" icon.
On your testcase case, it is not so obvious to reproduce.

I think it's either a DOM or Event problem but not a XP APPs

Comment 5

[Axel Hecht]

If you add a 
return false;
to 
grabElm,
the behaviour changes a bit. I don't get the same drag problems, but others.
When moving out to the top of the window, I get into the same situation as
described. I guess.

Comment 6

[Markus Hübner]

confirming - build 2002011503 on win-xp.
I have come across this "behaviour" on a number of websites.

Comment 7

[Blake Ross]

Not an xpapps bug, this is some lower level event issue.

Comment 8

[Marc Boullet]

OK, I will try to summarize what I understood about this bug:

1. When an event is fired, it generally executes the event handler, if any,
   set for this event, then performs the default action for the event (e.g.
   a click on link will execute first the onclick handler, if present,
   then will follow the link (default action)).
2. The default action for an image is to be non draggable, thus the "ø".
3. To prevent the default action, there are two ways:
    - the old one : "return false;" from the event handler
    - the DOM2 one: "e.preventDefault();" anywhere in the event handler
   Both work fine if added to test case 61431 (i.e. when the handler was set by
   "element.onmousedown=.....").
4. If the event handler has been set through DOM2 addEventListener(...)
   "return false;" doesn't work any longer while "e.preventDefault()" still
   works fine.
   Is that a bug or a normal behaviour ?
   I'm not shocked since when you set the event handler through DOM2, it seems
   normal to stop the default action through DOM2.
   
5. In any case, there is the bug Axel mentionned in comment #5:
   if, while dragging, you move the mouse cursor outside of the document window,
   and release the mouse there, the mouseup event which occured outside of the
   document window is not sent to the mouseup handler. When
   the mouse is moved back in the document window, dragging continues.

   To prevent that, I think that Mozilla should fire an onmouseup event when
   the cursor moves outside the document window AND there is a custom mousemove
   event handler for the target (or anything else better). IE 5.5 behaves
   correctly.

In any case, the summary of this bug should be changed, by somebody with
more credentials than I have, to reflect the latter point. 
   

   

Comment 9

[/\/\arcio Galli]

Johnny / jst, 

I guess this one is invalid right? for me, comments by  Marc Boullet are
correct. Is necessary to add the e.preventDefault() so the default dragging of
image (by the browser) will not apply (and affect the developer drag behavior).

Jose, 

Please add e.preventDefault(); to your drag handler and provide input for us please.

Comment 10

[Johnny Stenback (:jst)]

Makes sense to me, but I'll let joki have the final call here.

Comment 11

[Marc Boullet]

Attachment: modified test case with the addition of e.preventDefault()

Comment 12

[José Jeria]

Yes, now it works fine, thanks for the help.
But somehow I still think this should be done automatically.

I agree that the default action is that the image is not draggable, but after
setting an handler by elm.onmousedown this should not happend anymore. 

If you remove the e.preventDefault(); it works 90% of the times, if you follow
the logic made in comment 8, this should not happend. 

Well, i am happy it works with the preventDefault though, just some thoughts
about it.

Thanks

Comment 13

[joki (gone)]

Although I generally agree that with the default action being non-draggable that
we shouldn't be getting the sometimes works, sometimes doesn't thing I
definitely agree that this testcase should require e.preventDefault to work
properly.  The browser doesn't automatically cancel its default action due to
the registration of the a mousedown listener because many mousedown listeners
are intended to work in addition to the browser's default action, not instead of
it.  I'm going to go ahead with the invalid mark on this.

Comment 14

[Marc Boullet]

filed a new bug # 127887 for comment #8 point 5.

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 169710 has been marked as a duplicate of this bug. ***

Comment 16

[Vladimir Ermakov]

verifying