Closed Bug 424390 Opened 17 years ago Closed 8 years ago

Implement MouseEvent.x / MouseEvent.y (for CSSOM View)

Categories

(Core :: DOM: Events, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox53 --- fixed

People

(Reporter: jeresig, Assigned: ori)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-complete, Whiteboard: [parity-chrome][parity-opera][parity-IE][parity-safari][parity-webkit][parity-blink])

Attachments

(1 file, 1 obsolete file)

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)
Whiteboard: [parity-chrome][parity-opera][parity-IE][parity-safari][parity-webkit][parity-blink]
Kan-Ru, I wonder what you think about this question, as the module owner - it came up on the #qa channel recently.
Flags: needinfo?(kchen)
Attached patch Patch with tests (obsolete) — Splinter Review
Attachment #8806536 - Flags: review?(bugs)
(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.
Flags: needinfo?(kchen)
(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.
Assignee: nobody → ori
Attachment #8806536 - Attachment is obsolete: true
Attachment #8806861 - Flags: review?(bugs)
Attachment #8806861 - Flags: review?(bugs) → review+
Keywords: checkin-needed
Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e8c6f15ad696 Implement MouseEvent.x / MouseEvent.y (for CSSOM View). r=smaug
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Blocks: cssom-view-1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: