John Resig Reporter
	Description • 16 years ago

Currently all browsers implement this property (which is, essentially, clientX and clientY renamed), save for Gecko:
http://www.quirksmode.org/dom/w3c_cssom.html#mousepos

Adding this would help improve cross-browser compatibility and help us comply with CSSOM:
http://www.w3.org/TR/cssom-view/

	Martijn Wargers (dead)
	Comment 1 • 16 years ago

According to: http://msdn2.microsoft.com/en-us/library/ms535863(VS.85).aspx
"
y	Sets or retrieves the y-coordinate, in pixels, of the mouse pointer's position relative to a relatively positioned parent element.
"
"
clientY	Sets or retrieves the y-coordinate of the mouse pointer's position relative to the client area of the window, excluding window decorations and scroll bars.
"
So there seems to be a real difference between .y and .clientY, afaict. Unless the msdn documentation is wrong (which I doubt).

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 2 • 16 years ago

I'm not at all sure we should implement .x/.y, they are just aliases to
clientX/Y. I might even propose to remove .x/.y from the spec.
http://dev.w3.org/csswg/cssom-view/#the-mouseeventview-interface

	Ori Avtalion (salty-horse) Assignee
	Comment 3 • 8 years ago

Years have passed, and .x/.y remain in the CSSOM draft. Is there still resistance to implementing this?

https://drafts.csswg.org/cssom-view/#dom-mouseevent-x

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 5 • 8 years ago

Kan-Ru, I wonder what you think about this question, as the module owner - it came up on the #qa channel recently.

	Kan-Ru Chen [:kanru] (UTC+9)
	Comment 7 • 8 years ago

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #5)
> Kan-Ru, I wonder what you think about this question, as the module owner -
> it came up on the #qa channel recently.

I think Olli's opinion matters more.. Note I'm not a module owner of DOM::Events; did you meant to comment this bug?

IMO we have not have .x/.y for this long and we are still doing fine so maybe change this won't improve webcompat very much. Though implementing them wouldn't hurt either.

	Ori Avtalion (salty-horse) Assignee
	Comment 8 • 8 years ago

(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #7)
> IMO we have not have .x/.y for this long and we are still doing fine so
> maybe change this won't improve webcompat very much. Though implementing
> them wouldn't hurt either.
I revived this after encountering a page that was broken on Firefox.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 9 • 8 years ago

Comment on attachment 8806536 [details] [diff] [review]
Patch with tests

not sure why dispatchEvent is needed, but fine.

	Ori Avtalion (salty-horse) Assignee
	Comment 10 • 8 years ago

(In reply to Olli Pettay [:smaug] from comment #9)
> not sure why dispatchEvent is needed, but fine.
I can change it. Is it enough to call the MouseEvent constructor and check x/y?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 11 • 8 years ago

I think that should be enough there.

	Pulsebot
	Comment 13 • 8 years ago

Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e8c6f15ad696
Implement MouseEvent.x / MouseEvent.y (for CSSOM View). r=smaug

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 14 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/e8c6f15ad696

	Chris Mills [:cmills]
	Comment 15 • 7 years ago

I've updated the individual property pages:

https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/x
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/y

I've also added a note to the Fx53 release notes:

https://developer.mozilla.org/en-US/Firefox/Releases/53#DOM_HTML_DOM