1.36 KB, text/html
(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.
PDT: Nominating nsbeta3+. Standards Compliance.
I am the virtual joki.
Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.
I am seeing this on NT too, changing platform and OS to All.
*** Bug 45558 has been marked as a duplicate of this bug. ***
PDT agrees P2 since lots of content on the web uses mouseOver
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.
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...
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...
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.
This appears to have been a typo in the registration of mousemove listeners. Fixed now.
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.
*** Bug 52620 has been marked as a duplicate of this bug. ***