Mozilla supports listening to a DOMMouseScroll event and exposes the properties clientX clientY pageX pageY on the event object the event listener receives. However the number values exposed do not seem to be correct. With Firefox 1.5 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060728 Firefox/18.104.22.168) when you use the test case <http://home.arcor.de/martin.honnen/mozillaBugs/domLevel2/events/DOMMouseScrollClientXYTest1.html> and first move the mouse so that the mousemove event properties are shown and then use the scroll wheel so that the DOMMouseScroll event properties are shown you will find that the values for the DOMMouseScroll event are much larger than the values for mousemove. The values for the DOMMouseScroll event should be the same as the last values reported for the mousemove event. With a Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060911 Minefield/3.0a1) the values for DOMMouseScroll are always reported as 0.
According to Wikipedia  this event only works in XUL.  http://en.wikipedia.org/wiki/DOM_Events#XUL_events
OS: Windows XP → All
Hardware: PC → All
Summary: event object of DOMMouseScroll event exposes clientX, clientY and pageX. pageY properties with incorrect values → Event object of DOMMouseScroll event exposes clientX, clientY and pageX. pageY properties with incorrect values
The problem appears to be in nsEventStateManager::DoScrollText, it manually creates a DOMMouseScroll event and hands it client coordinates which it got from the nsMouseScrollEvent. Not only that, but the new event has no widget... On trunk I guess it needs to call nsEventDispatcher::CreateEvent instead.
Neil, is this something we should be fixing for 1.9?
(In reply to comment #3) >Neil, is this something we should be fixing for 1.9? My main development machine doesn't actually have a wheel mouse, I had to borrow another machine to debug this! I've no idea if it was a regression. If it isn't then I say that people will just have to make do as they have always done.
I can confirm this bug.
This should be fixed now by bug 369793. And the testcase works fine here.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Can we add a test to the test suite?
Will have to extend nsIDOMWindowUtils to dispatch DOMMouseScroll events
Playing around with DOMMouseScroll, I found out about this bug and I'm still getting this with firefox 22.214.171.124 (Linux and XP versions alike). I haven't seen how to recover the correct values anywhere so I dug in and I managed to figure out the corresponding values between what the event returns and the real values: real event.pageY = event.target.top + (event.clientY-8)/15 + document.html.'margin-top' real event.pageX = event.target.left+(event.clientX-8)/15 + document.html.'margin-left' where event.target is the element the mouse is hovering, .top is its real 'top' coordinate, and document.html.'margin-top' is the top margin of the html element, and the counterparts for the X coordinate. Adapting these to the body scroll you get ClientX/Y. I don't know how relevant this is and whether it is even an issue with FF3 being close. Also, if this post is somehow out of context or already dealt with, sorry for the inconvenience.
This is fixed on trunk (== FF3), as I indicated in comment 6.
That much I know, but most people still use FF2, at least until a final release of FF3, and I need this now. Just thought I'd point this out since it might still be a little useful and I was unable to find the values I gave anywhere.
Thank you poudro -- I find the hack useful (since you pointed out that FF3 isn't being widely released for a few more months) That small point seems to be lost here
You need to log in before you can comment on or make changes to this bug.