Bug 10809 - evt.x and evt.y are not correctly supported
Summary: evt.x and evt.y are not correctly supported
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: PC OS X 10.4
: P4 Normal
Assignee: Nobody
URL: http://www.gtalbot.org/BrowserBugsSec...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2006-09-10 20:33 PDT by Gérard Talbot
Modified: 2012-08-20 06:24 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gérard Talbot 2006-09-10 20:33:18 PDT
x and y properties, as defined in MSIE's DHTML object model, will return the offset of the mouse (when the event occured) from within a relatively positioned element, otherwise (if there are no relatively positioned containing block within the containment hierarchy) from its offsetParent.

Steps to reproduce:
-------------------
1- Load provided URL
2- hover the mouse over each of the 4 corners of the any/both of the green lime rectangles

Actual results in Swift 0.1
---------------------------
The returned values are as if the lime green rectangles were not relatively positioned elements.

Expected results
----------------
The returned coordinates in the input should correspond to the values written in each corner. E.g. event.x should be 0 and event.y should be 100 when hovering the mouse over the bottom left corner.

References:
-----------
"Sets or retrieves the y-coordinate, in pixels, of the mouse pointer's position relative to a relatively positioned parent element."
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/y.asp
Comment 1 Gérard Talbot 2007-03-19 14:28:15 PDT
Also

http://www.gtalbot.org/DHTMLSection/PositioningEventXY.html
Comment 2 Gérard Talbot 2007-06-24 09:30:56 PDT
Hello,

I reiterate that this bug is still happening, including in Safari 3.0.2 build 522.13.1. This bug may not be a serious bug (hence, I am lowering down priority from P2 to P4) since event.x, event.y are rather "rare birds" in DHTML-driven webpages but I assure you that Safari 2+ do not implement event.x, event.y correctly, that is by following the way its initial implementor (Microsoft IE) implemented it.
Comment 3 Alexey Proskuryakov 2007-06-24 10:39:42 PDT
Confirmed with r23751, sorry that it took so long!

One minor comment: as of MSIE 7, the bottom right corner seems to have coordinates (99, 99), while the test expects (100, 100). I haven't tested with MSIE 6.
Comment 4 Gérard Talbot 2007-06-24 18:12:49 PDT
Yes, you're right: 99x99 is correct. 
The image for the test case should have been 101 by 101 and then offer the 4 coordinates (0, 0), (0, 100), (100, 0) and (100, 100) so that the area 101x101 represent x-distance by y-distance.
To cover a 0 to n dimension-distance, one needs n+1 pixels.
Comment 5 Gérard Talbot 2007-06-24 18:45:00 PDT
Testcase code and image updated to reflect that missing pixel. The image has width="101" and height="101".
Good catch, Alexey! Cheers!
Comment 6 Gérard Talbot 2008-05-02 23:18:45 PDT
evt.x and evt.y now seem to be defined by 
W3C CSSOM View Module
W3C Working Draft 22 February 2008
http://www.w3.org/TR/cssom-view/#the-mouseeventview-interface
so following MSIE's DHTML object model may not be suited or recommended anymore..
Comment 7 Gérard Talbot 2009-06-13 11:12:12 PDT
References:
-----------
"Sets or retrieves the y-coordinate, in pixels, of the mouse pointer's position
relative to a relatively positioned parent element.
(...)
If the event firing element is relatively positioned, then the y-coordinate from the boundary of the element is returned. If the event firing element and all of its parent elements are not relatively positioned, then the y property returns a coordinate relative to the body element.
"
MSDN documentation, y Property (event, Event Constructor)
http://msdn.microsoft.com/en-us/library/ms535164(VS.85).aspx



"
The y attribute, on getting, must return the value of pageY. (...)
The pageY attribute, on getting, must return the vertical coordinate, as number of CSS pixels, of the position where the event occurred relative to the origin of the canvas.
"
CSSOM View Module, WD 22 February 2008
http://www.w3.org/TR/cssom-view/#mouseeventview-y
and
http://www.w3.org/TR/cssom-view/#mouseeventview-pagey



Right now, Safari 4.0 final release build 530.17 does not comply with the MSDN specification nor with the W3C WD CSSOM View Module specification as it treats x and y properties like clientX and clientY (relative to viewport) properties and not as pageX and pageY (relative to canvas) properties.

regards, Gérard
Comment 8 Alexey Proskuryakov 2009-06-13 14:02:24 PDT
<rdar://problem/6970140>
Comment 9 Gérard Talbot 2011-01-13 11:25:06 PST
Hello all,

The CSSOM WD **_changed_** the definition of evt.x and evt.y: these values are now supposed to duplicate clientX and clientY.

"
The clientX attribute, on getting, must return the x-coordinate of the position where the event occurred relative to the origin of the viewport.

The clientY attribute, on getting, must return the y-coordinate of the position where the event occurred relative to the origin of the viewport.

The x attribute, on getting, must return the value of clientX.

The y attribute, on getting, must return the value of clientY.
" 
CSSOM View Module
W3C Working Draft 04 August 2009
http://www.w3.org/TR/cssom-view/#dom-mouseevent-x

MSDN on the other hand still claims evt.x and evt.y should return mouse pointer's offset from the closest relatively positioned parent. 

regards, Gérard
Comment 10 Simon Fraser (smfr) 2011-01-13 11:28:39 PST
Do we have any idea how common event.x and event.y are in the wild?
Comment 11 Gérard Talbot 2011-01-13 12:44:53 PST
Simon,

evt.x and evt.y are pretty "rare birds". 
I'd be surprised if more than 1% of DHTML-driven webpages use x and y event properties. 
I'd be surprised if more than 0.01% of all webpages use x and y event properties.

Gérard