352179 - Event object of DOMMouseScroll event exposes clientX, clientY and pageX. pageY properties with incorrect values

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Martin Honnen]

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:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6) 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.

Comment 1

[Adam Guthrie]

According to Wikipedia [0] this event only works in XUL.

[0] http://en.wikipedia.org/wiki/DOM_Events#XUL_events

Comment 2

[[e-mail]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Neil, is this something we should be fixing for 1.9?

Comment 4

[[e-mail]]

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

Comment 5

[Tuom Larsen]

I can confirm this bug.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

This should be fixed now by bug 369793.
And the testcase works fine here.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Can we add a test to the test suite?

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Will have to extend nsIDOMWindowUtils to dispatch DOMMouseScroll events

Comment 10

[poudro]

Playing around with DOMMouseScroll, I found out about this bug and I'm still getting this with firefox 2.0.0.13 (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.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

This is fixed on trunk (== FF3), as I indicated in comment 6.

Comment 12

[poudro]

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.

Comment 13

[billy]

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