Bug 20878 – mousemove event not registered in frame different from where drag started

• Component: WebCore Misc.
• Status: NEW

[Peter Müller]

Test case: http://fumle.dk/drag_issue/
The test case is also attached as a zipped file for reference.

Webkit behaves differently than IE and Gecko when dragging an element from one frame to another when the originating frame has user selection disabled. In Gecko and IE the mousemove event will be registered in the frame the mouse is hovering, while in Webkit the mousemove event will be registered in the originating frame.

An explanation of the test case:
- The background color of the frame where a mousemove event i registered will turn light green.
- The debugging box in the top right hand corner displays the mouse coordinates and the filename of the document in the frame where the mousemov event is handled.

To reproduce:
1) Click and hold the mouse button on the left frame. Move the mouse out of the frame. The expected behavior is to select text and handle the mousemove event in the frame the mouse was pressd in.

2) Click and hold the mouse button on the right frame. Move the mouse out of the frame. The expected behavior from Gecko and IE is to not select any text, since text selection is disabled for the frame, and to handle the mousemove event in the frame the mouse is hovering. In Webkit the mousemove event is handled like when text selection was not disabled.


Reproduced in:
Safari 3.1.2 (525.21) on Windows XP pro
Safari 3.1.2 (5525.20.1) on Mac OS 10.5.4
Safari nightly on Windows XP pro
Safari nightly on Mac OS 10.5.4

[Peter Müller]

Created attachment 23472 [details]
Zipped test case linked to in the description

[Alexey Proskuryakov]

Confirmed with r36292 and with shipping 10.5.5 Safari/WebKit.

Steps to reproduce:
1) Click in the right frame.
2) Without releasing the mouse button, drag to the left frame:

Expected results: The left frame should be highlighted instead of the right one.
Actual results: the right frame remains highlighted.