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/
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).
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
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
Summary: Implement event.x / event.y (for CSSOM) → Implement MouseEvent.x / MouseEvent.y (for CSSOM View)
Kan-Ru, I wonder what you think about this question, as the module owner - it came up on the #qa channel recently.
(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.
(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.
Comment on attachment 8806536 [details] [diff] [review] Patch with tests not sure why dispatchEvent is needed, but fine.
Attachment #8806536 - Flags: review?(bugs) → review+
(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?
I think that should be enough there.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/e8c6f15ad696 Implement MouseEvent.x / MouseEvent.y (for CSSOM View). r=smaug
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
You need to log in before you can comment on or make changes to this bug.