Bug 26723

Summary:

clientX,Y , screenX , Y always (0, 0) in dragstart event

Product:

WebKit

Reporter:

Jessie Berlin <jberlin>

Component:

WebCore JavaScript

Assignee:

Jessie Berlin <jberlin>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

jberlin, mrowe

Priority:

Version:

528+ (Nightly build)

Hardware:

OS:

Windows 7

Attachments:

Description	Flags
Test case showing the clientX, pageX, and screenX values in dragstart	none
Fix: Make sure the m_mouseDown event is set correctly	none

Jessie Berlin

Reported 2009-06-25 09:46:11 PDT

event.clientX, event.clientY, event.screenX, event.screenY, event.pageX, and event.pageY all report 0 in a dragstart handler on windows (not on mac). This makes it difficult to use setDataImage(image, x, y) if you want to use the coordinates of the mousedown for the x and y values.

Attachments
Test case showing the clientX, pageX, and screenX values in dragstart (1.31 KB, text/html) 2009-06-25 09:47 PDT, Jessie Berlin	no flags	Details
Fix: Make sure the m_mouseDown event is set correctly (6.43 KB, patch) 2009-06-26 12:36 PDT, Jessie Berlin	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Jessie Berlin

Comment 1 2009-06-25 09:47:05 PDT

Created attachment 31861 [details] Test case showing the clientX, pageX, and screenX values in dragstart

Jessie Berlin

Comment 2 2009-06-25 11:49:23 PDT

On windows, this can be fixed setting m_mouseDown to event.event() inside bool EventHandler::handleDrag(const MouseEventWithHitTestResults& event) before the following line: m_mouseDownMayStartDrag = dispatchDragSrcEvent(eventNames().dragstartEvent, m_mouseDown) && !m_frame->selection()->isInPasswordField(); Which makes sense, because it doesn't seem to be that m_mouseDown is ever initialized, so it is an empty event that is sent to bool EventHandler::dispatchDragEvent(const AtomicString& eventType, Node* dragTarget, const PlatformMouseEvent& event, Clipboard* clipboard) where the actual event that is used to get information for the event.clientX and event.clientY calls is initialized with that empty event's position (aka (0,0) ). However, I am not sure why this works on the mac. I am currently trying to see if making the change breaks anything on the mac.

Jessie Berlin

Comment 3 2009-06-25 14:36:12 PDT

I have a patch, I just need to write the test for it.

Jessie Berlin

Comment 4 2009-06-26 12:36:21 PDT

Created attachment 31943 [details] Fix: Make sure the m_mouseDown event is set correctly

Mark Rowe (bdash)

Comment 5 2009-06-26 12:41:08 PDT

Comment on attachment 31943 [details] Fix: Make sure the m_mouseDown event is set correctly > Index: WebCore/page/EventHandler.cpp > =================================================================== > --- WebCore/page/EventHandler.cpp (revision 45259) > +++ WebCore/page/EventHandler.cpp (working copy) > @@ -354,6 +354,8 @@ bool EventHandler::handleMousePressEvent > > m_mouseDownWasSingleClickInSelection = false; > > + m_mouseDown = event.event(); > + > if (event.isOverWidget() && passWidgetMouseDownEventToWidget(event)) > return true; You should remove the now-redundant assignment to m_mouseDown from EventHandler::mouseDown in EventHandlerMac.mm. > + <body onload="Test.runTest()"> > + <h3>Test for <a href='https://bugs.webkit.org/show_bug.cgi?id=26723'>WebKit bug 26723</a>: clientX,Y , screenX , Y always (0, 0) in dragstart event</h3> > + <div id="notDraggable" class="test"> > + DON'T BOTHER TRYING TO DRAG ME > + </div> > + <div id="alsoNotDraggable" class="test" style="display: inline-block;"> > + DON'T BOTHER TRYING TO DRAG ME > + </div> > + <div id="draggable" class="test" style="display: inline-block;"> > + DRAG ME! > + </div> > + <div id="result"></div> > + </body> > +</html> What're the two non-draggable elements about? They don't seem to be used in the test. If they're not needed, it would make the test clearer if they weren't present. r=me

Jessie Berlin

Comment 6 2009-06-26 13:30:47 PDT

I removed the now redundant setting of m_mouseDown from EventHandlerMac.mm and also removed the extraneous non-draggable elements from the layout test. committed with revision 45278

Note You need to log in before you can comment on or make changes to this bug.