public void onMouseSomething(Widget sender, int x, int y)
Where x and y are the clientX and clientY of the mouse event. They
measure in pixels from the inside of the browser window, from the
"viewport". clientX and clientY are not very useful if you are working
on a scrolling page because it does not give absolute coordinates; you
get coordinate relative to the browser window, not the webpage. What
is really far more useful is pageX and pageY. pageX and pageY measure
from the edge of the web page itself, so you get a useful mouse
coordinate no matter where you are scrolled to.
pageX and pageY aren't offical W3C event properties, but they are
supported naively by everything but IE. It is equivalent to
pageX = clientX + document.body.scrollLeft;
pageY = clientY + document.body.scrollTop;
I can't find a way to get the body's scrollLeft and scrollTop that I
can see without dipping into javascript.
public static native int getScrollTop() /*-{
return $doc.body.scrollTop;
}-*/;
I think it is likely that enough people would benefit from knowing to
where on the page they are scrolled to warrent having the methods
getScrollLeft() and getScrollTop() in Client.Window. I think you
(Google) should consider adding them.
For nonscrolling apps, the clientX to pageX API change would be
transparent. For people who write apps that scroll, it means you don't
have to put in
int pageX = x + getScrollLeft();
everywhere in your program.
Here's an old quirksmode on pageX vs. clientX.
http://www.quirksmode.org/js/events_properties.html
Another possiblity is passing along some sort of MouseEvent object,
like in Swing or regular DOM events, that has all the properties anyone
wants.
What does the rest of the community think about pageX vs. clientX?
Did you ever solve this without resorting to javascript?
If you resorted to javascript can you post your code?...getting it to
work in all the supported browsers is problematic.
- Bob L.