47022 - Drag-and-drop support suppresses DOM1 mouseOver and mouseUp event handling, breaks examples

Status: VERIFIED FIXED

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

Description

[Bob Kanefsky]

(I thought at first this was the same as Bug 43258, but the reporter of that bug 

pointed out some important differences, so I'm reporting this as a separate bug 

to be tracked.  I'm rewriting all the relevant information below.)



Both the published DOM sample code at

  http://www.mozilla.org/docs/dom/samples/resize/

and my own application of it, developed to work unde Netscape 6 PR1,

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

worked great under Mozilla M15, but the

drag-and-drop behavior is broken under Mozilla build 2000072520.

It can no longer tell what object on the page it's being dropped into.

I'm attaching a simplified test case.



I'll now describe the intended (M15) and actual (M17) behavior of four tests

with these two web pages and the attachment.



M15 (intended) behavior of Mozilla DOM sample:  resizes

M17 (broken) behavior:  moves



M15 (intended) behavior of Roving Mouse planetary application:

  Can drag planets into the "resize box" to scale them relative to each other.

M17 (broken) behavior:

  Planet can't tell where it's being dropped, so the page was completely

  broken at first.  I now have a workaround that makes it assume any drag

  ends in the resize box, but now you can't take a planet out of the box

  if you don't like the result.  Also, it prevents me from adding the moon

  icon I was planning to add, to make a planet's moons appear on the page,

  and other applications of drag-and-drop.



Two tests with the attached test case:



Test 1:  Drag from the red ball to the blue ball (i.e., point at red, mouse down, 

move to blue, mouse up).



Expected behavior (works under M15):  Just like dragging the text:  No visible 

changes provided for in script, and events are

  Mouse Over red ball

  Mouse Down red ball

  Mouse Out red ball

  Mouse Over blue ball

  Mouse Up blue ball

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



Actual new behavior:  A transparent red-ball image is dragged, apparently the 

work of the native MacOS drag-and-drop support.  Events are:

  Mouse Over red ball

  Mouse Down red ball

    [moving the mouse to the blue ball here does nothing]

    [then dropping it suddenly causes 3 events]

  Mouse Out red ball

  Mouse Up blue ball

  Mouse Out red ball

  Mouse Over blue ball



The above happened after Mozilla's ablity to visit URLs had gotten suppressed by 

some other unidentified bug.  On a second run, the last few events never happened 

and instead it opened the red-ball image as a document.  Apparently dragging an 

inline image within a page now opens the image, just like dragging an inline 

image or link to another window or dragging a file from the desktop to a browser 

window.



Test 2:  Further from what I'm after, but closer to how the interfering feature 

may be intended to work:  Drag the red ball through the blue ball and then drop 

it onto another browser window (i.e. point at red ball, mouse down, move to blue 

ball, move to other window, mouse up).



Expected results:  the blue ball should get a MouseOver event and a MouseOut 

event, and then perhaps the other window should open the image if you insist.



Actual results:

  Mouse Over red ball

  Mouse Down red ball

  Mouse Out red ball

and nothing more; second window then opens red ball image.

If the mouse is later moved back over the first window,

a second Mouse Out red ball occurs.



If there's a higher level interface for application-specific drag-and-drop within 

a page, I couldn't find any documentation or examples.  Breaking DOM1 behavior 

that worked in a previous milestone release probably qualifies as a bug whether 

there's a better interface available or not, since Mozilla is supposed to be 

DOM1-compliant.

Comment 1

[Bob Kanefsky]

Attachment: Simplified test case (red and blue text, red and blue ball)

Comment 2

[ckritzer (gone)]

PDT: Nominating nsbeta3+.  Standards Compliance.

Comment 3

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

I am the virtual joki.

Comment 4

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

Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.

Comment 5

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

I am seeing this on NT too, changing platform and OS to All.

Comment 6

[Masatoshi Kimura [:emk]]

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

Comment 7

[Phil Peterson]

PDT agrees P2 since lots of content on the web uses mouseOver 

Comment 8

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

Hmm... if I replace all occurrences of

window.onmouse****

with 

document.body.onmouse****

(where **** is up/move) the sample works. Specifically note that I do not need 
to change the sample so that beginDrag would return false.

Next step is to figure out why window.onmouse*** handlers don't get called.

Comment 9

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

Btw, the workaround is for the resize test case. The Simplified testcase seems 
to work as is. I believe it now works because pinkerton fixed bug 43258 
(mousemove listening prevents mouseup on drag event). The trick is to return 
false at the right place in the script...

Comment 10

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

For the testcase in URL (the resize case) I tracked down when this broke. It 
works in nightly build 2000-08-28, but does not work in 2000-08-31 (there are 
no builds in between).

That leaves quite a few checkins in there, but just about the only one I can 
think of is a checkin from vidur. He added some window event owner stuff.

vidur suggested I place breakpoints in nsJSWindow.cpp. I see we seem to 
succesfully set mousemove and mousedown properties...

Comment 11

[joki (gone)]

Okay, looks like a type got introduced into the code at some point.  The fix is 
in my tree so I'll check it in.

Comment 12

[joki (gone)]

This appears to have been a typo in the registration of mousemove listeners.  
Fixed now.

Comment 13

[Bob Kanefsky]

Verified on attachment and on revised
   http://www.roving-mouse.com/planetary/sizes.html
with build id 20000091509, MacOS 9

http://www.mozilla.org/docs/dom/samples/resize/ also works, except for
extraneous outline square during drag.

Thanks.

Comment 14

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

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