Bug 10809 – Implement MouseEvent's x and y in terms of clientX and clientY

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Gérard Talbot (no longer involved)]

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

[Gérard Talbot (no longer involved)]

Also

http://www.gtalbot.org/DHTMLSection/PositioningEventXY.html

[Gérard Talbot (no longer involved)]

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.

[Alexey Proskuryakov]

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.

[Gérard Talbot (no longer involved)]

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.

[Gérard Talbot (no longer involved)]

Testcase code and image updated to reflect that missing pixel. The image has width="101" and height="101".
Good catch, Alexey! Cheers!

[Gérard Talbot (no longer involved)]

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..

[Gérard Talbot (no longer involved)]

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

[Alexey Proskuryakov]

<rdar://problem/6970140>

[Gérard Talbot (no longer involved)]

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

[Simon Fraser (smfr)]

Do we have any idea how common event.x and event.y are in the wild?

[Gérard Talbot (no longer involved)]

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

[Anne van Kesteren]

It seems we correctly implement these now, but we could tidy the code up.

[Anne van Kesteren]

Pull request: https://github.com/WebKit/WebKit/pull/21633

[EWS]

Committed 271890@main (e0208f9d2075): <https://commits.webkit.org/271890@main>

Reviewed commits have been landed. Closing PR #21633 and removing active labels.