301255 - Mouse events sent to wrong frame when mousedown event occurs over non-text element

Status: NEW

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

Description

[Frank Faubert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

I have written a cross-frame drag-and-drop library in JavaScript that works well
in both Firefox and IE.  However, I have noticed some quirkiness in Firefox that
I hope you can fix.  I have thrown together an (admittedly hack) example that
shows off a problem where the mousemove event is sent to the wrong frame,
depending on where the mousedown event occurs.

If there is a workaround for this please let me know.  I have yet to find one.

Reproducible: Always

Steps to Reproduce:
1. Pull up http://dev.sane.com/open/mousemove/
2. Hold down the left mouse button over the text "Click Here" in the left frame.
3. While holding the button down, move the mouse into the right frame.  Note
that the mousemove event is sent to the correct frame.
4. Release the mouse button and go back to the left frame.
5. Hold down the left mouse button in the blue box in the left frame, but -not-
over the text "Click here".
6. While holding the button down, move the mouse into the right frame.  Note
that the mousemove event is sent to the incorrect frame.


Actual Results:  
Mouse events are sent to the wrong frame.

Expected Results:  
Mouse events should be sent to the frame that is under the cursor, regardless of
what the mouse was over when the button was held down.

Real world case: I have drag-and-drop enabled a table cell that contains a link.
 Cross-frame drag-and-drop works if I hold down the button over the link, but
not if I hold down the button elsewhere in the table cell.  For usability
purposes, I do not want to restrict the user to having to hold the button down
over the link.

Comment 1

[Martijn Wargers (dead)]

I can see the bug with the latest nightly trunk build.
Reporter, could you perhaps attach the testcase to the bug?
Without sounding too pessimistic, I think this is a bug that can take a long
time before it gets fixed.
I think bug 294844 is related.

Comment 2

[Frank Faubert]

Attachment: Testcase - Frameset

Comment 3

[Frank Faubert]

Attachment: Testcase - Frame body

Comment 4

[Frank Faubert]

Note: Adding "-moz-user-select: none;" to the html element fixes the problem for me.

Comment 5

[Martijn Wargers (dead)]

Yes, probably there is some selecting going on, which is capturing events.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This sounds like the right behavior in the face of capture...