Javascript mousemove Event Brouhaha Resolved

Hey all! I’ve been playing with javascript for some time, and I have something very interesting for my JS brethren out there.

There has been long-standing confusion regarding this big question: “How to get mouse coordinates on a page with the mousemove event?”

My googling lead me to this page that says that its impossible to do this. But this did not satiate my itch, so I did some of my own digging (or scratching, if you please 🙂 ).

I conclude that while this question has no all-pleasing answer, the task is quite doable (though in a useless scientific-theory kind of way).

This post addresses this question in detail. And I’ll take this step by step.

The mouseover event

This event is supposed to be generated whenever the mouse is moved in the “client area” – the white area where the page is rendered.
This event has 6 sets of properties (in all browser taken together):

  • clientX, clientY
  • layerX, layerY
  • offsetX, pageY
  • pageX, pageY
  • X, Y
  • screenX, screenY

Now, thats the easy part. The major PITA is that not all browsers support all these properties. And, if two browsers support the same property, they don’t implement them the same way!

The only exception to this confusion is the screenX/Y pair: they are available consistently across all browsers, and all do the same thing – get the coordinates with respect to the top left corner of you screen. But then, this value doesn’t really have much use, does it? 😐

And here’s how the rest of the properties behave cross-browser:

1. Firefox – both 2 and 3

  • offsetX/Y and X/Y pair are undefined. So if you try to read them, you will get “undefined”. No, not even null. Plain undefined.
  • clientX/Y, pageX/Y and layerX/Y all get us the coordinates of the mouse with respect to the top-left corner of the client area, regardless of the padding of ‘body’.
    So whatever be the padding of your page’s body, you’ll always get the same values, no matter what.
    This is kind of standard across browsers too, except that different properties return this value.
  • Now then, there’s the quirk: FF2 does something strange with layerX/Y: it is not equal to pageX/Y and clientX/Y – instead they it is always (1+clientX)/(1+clientY) – God knows why! This is probably because it does not count the border of the client area. But again, defining the client area’s border is like fighting foo.

2. Konquerer 3.5

It is this browser’s implementation that has appealed to me the most.

  • All the properties are defined. clientX/Y, pageX/Y, layerX/Y and X/Y all mean the same thing – the coordinate w.r.t the top-left corner of the client area.
  • offsetX/Y gives the coordinate of the mouse inside the current element, where current element is the element over which your mouse is hovering.
  • A point to note is that offsetX/Y  gives the coordinate from the outer edge of the border(in case of more-than-1px-wide border) of the element – so margin is not counted, and the padding is considered as part of the element.

3. Opera 9

  • Here, layerX/Y is undefined.
  • clientX/Y, pageX/Y and X/Y are the same as that in Firefox and Konqueror.
  • But offsetX/Y is a different story. It behaves like in Konqueror, but it returns the coordinate w.r.t the top-left corner where the padding ends!
  • Further, the padding region and border region are part of the “current element”, but when your mouse is in, like, the left padding region, the layerX is negative. Baaaad!
  • However, this behaviour is not repeated with the layerX/Y etc for the body – in the case of body, padding’s just as much a part of the client area as is the content.

4. Google Chrome

This browser, thankfully, adopts the konqueror standards. Perhaps that’s because the google guys liked that model too. (That says something about me, doesn’t it? :P)

But there still is one small difference — and I’ve saved that for the last! Noooo… don’t rush down to the end just now!

5. IE 7 and 6

  • Here, layerX/Y and pageX/Y are undefined.
  • clientX/Y and X/Y are the coordinates w.r.t the client area’s t-l corner (yeah, no padding).
  • But then, there’s a glitch (again). In IE, the mousemove event is generated very slowly – only when your mouse crosses an element’s boundary, or you are shaking the mouse rather too vigourously. Perhaps this was intended to be some kind of performance bonus, it is headache for us devs.
  • And, offsetX/Y behaves like in Konqueror, but the event is generated too slowly to really tell whether the padding is being included in the coordinates or not. IE’s weird as ever. Microsoft. Bleah!

I got the same result with IE 5.5 and IE 5, but the testing was not as thorough. Who cares, anyway.

BTW, I did my IE testing on both Windows machines, as well as my dear Ubuntu. I used ies4linux, of course.

Summary

In all, here are a few things to note:

  1. screenX/Y and clientX/Y work in all the above browsers.
  2. Firefox does not support offsetX/Y.
  3. All the rest support offsetX/Y, except that Opera pulls in all the padding shaggywag.
  4. IE has a very lousy “refresh-rate”. Hopeless, really.

Now for the final piece-o-cake:

Q: What happens when you drag your mouse out of the client area?
A: One would expect that mouse tracking should stop, and it does. But, Opera and Konqueror do one additional thing – they track the first point that lands outside the client area. This means that after tracking has stopped, one of the values in the clientX/Y pair (or X/Y or pageX/Y etc) may be negative! So watch out! But again, google chrome does not do this stunt – it does not track any point outside the client area. Nor do Firefox and IE.

Whew! What a marathon! I wonder if all this is any real use at all. Given that you know all this, you still have to do a browser detect to write any “portable” javascript.

I firmly believe that browser detection is bad for javascript – it is bad for the minority of users who use obscure browsers that implement a well-known-browser-compatible standard.

So I guess this info is for just alpha geeks who want such info just for the sake of it. But it satisfies my itch quite perfectly.

So then, Thank you. ¡Hasta luego! (bows and exits) 😀

Advertisements

8 thoughts on “Javascript mousemove Event Brouhaha Resolved

  1. it’s funny, the more i use Chrome (for windows), the more unstable it seems to get… crashes a lot more, can’t handle sites with flash, hangs every time i close a tab… all that to say, i’m switching back to Firefox

  2. Chrome is still under development… They themselves don’t advise you to make it your staple browser.
    I guess things won’t get really great until chrome comes out for linux 😛

    But I like the stand they’ve taken on implementing CSS and JS standards…

  3. Google Chrome: I have found that mouseclick position is reported incorrectly in event object when click occurs within an image map. Both layerY and offsetY (and likewise with the X coordinates) report the absolute position of the click in client area rather than position of click within the map element. Thus very difficult to reliably determine where click occurred within the image relative to left upper corner of image, especially if image is nested within other elements like divs/tables. This behavior is distinctly different than both Firefox/Mozilla and IE. Would appreciate suggestions for workaround.

  4. >you still have to do a browser detect to write any “portable” javascript

    Typically you only need the difference between values of screenX (or screenY) at onmousedown event and at onmousemove event (or at onmouseup event). This works for moving as well as resizing DHTML shapes and it is portable code.

  5. In FF I use pageX and pageY which give you the coordinates as they relate to the top-left corner of the rendered document. That way you know how far down a page the mouse is even if the document has been scrolled.

  6. @justin
    mm hmm.., Thats another interesting use of pageX and pageY.

    Howevery, you’d much better be using scrollTop and scrollLeft rather than pageX and pageY to get how much a document (or any other element for that matter) has been scrolled down.

    The benefit is twofold:
    1. your code will work just the way you want on all browsers
    2. it can be applied to any element (a textarea, a scrollable div etc) rather than just the document itself.

    cheers,
    jrh

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s