RESOLVED FIXED 26723
clientX,Y , screenX , Y always (0, 0) in dragstart event 
https://bugs.webkit.org/show_bug.cgi?id=26723
Summary clientX,Y , screenX , Y always (0, 0) in dragstart event
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
DetailsFormatted DiffDiff
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.