Something odd happened on the way to mousemove

Currently I'm working on a big revision of the Events Compatibility Tables. And no the new table is not yet online because I'm not ready yet.

Testing event support is really awesomely complicated. I've been working steadily for two weeks now, and I still find new bugs and oddities daily, and twice on Sundays.

In any case, I discovered something remarkable when I studied the mousemove event. It sheds light on the way browser vendors keep track of each other's implementations nowadays, and on things that can go wrong.

Update: The bug described in this entry is an OS problem, and not a browser bug.

When doing my new mousemove test I found a bug in IE5-7 that I was previously unaware of. When the user moves the mouse over the element, the mousemove event fires many times, as it should. However, when the user stops moving the mouse, IE5-7 continues firing the event every once in a while. This stops only when the mouse leaves the target element entirely.

~~This is obviously a bug: when the mouse does not move the mousemove event should not fire.~~

~~The IE team reacted correctly: the bug has been solved in IE8b1. When the mouse does not move any more the mousemove event stops firing, as it should.~~

~~However, this same bug was recently introduced in Safari (Windows) and Opera!~~

~~Safari 3.0 and Opera 9.26 support mousemove correctly, but Safari 3.1 and Opera 9.5b have copied the IE bug.~~

~~What seems to have happened is that the IE team took a close look at other browsers' mousemove implementation, discovered that the IE5-7 implementation was buggy, and decided to correct the bug.~~

Simultaneously, however, the Safari and Opera teams were also studying other browsers' mousemove implementation, discovered the IE5-7 bug and decided to implement it in their latest versions.

Their decision is understandable: it's a fact of life that web developers code with IE as baseline, and therefore other browsers must sometimes copy IE bugs.

Nonetheless, the position switch that IE and Safari/Opera have performed just now is unusual, and things like this shouldn't happen too often.

There are lessons to be drawn here. Although all four browser vendors are paying close attention to each other's implementation, it might make sense to discuss potential improvements before actually implementing them. That won't be easy, certainly not for the IE and Safari teams who're part of large companies that have a history of secrecy, but still it's something to be considered.

Besides, it makes me wonder about the wisdom of copying IE's bugs. After all, now that IE is moving quite close to the standards, the IE team may suddenly decide to solve a bug that has been left untouched for many versions.

Although I'm very happy about the increased communication between the various browser vendors, it seems they should cooperate even closer in order to prevent such odd reversals of position. (And the Safari team should send representatives to interesting browser vendor panels, but that's another story.)

Comments

1 Posted by Mathias on 2 April 2008 | Permalink

This makes me think of a similar observation I did in an other situation some years ago.
After some long debuging sessions it turned out, that my optical mouse continuously (but not always) sent very small positioning corrections that where interpreted as mouse-movements. A move-event was triggered even when nobody touched the mouse. :-)

2 Posted by Mark Wubben on 2 April 2008 | Permalink

Did you consider that the extra events are caused by a glitch in the OS, as Mathias described above, and that IE8 now works around this glitch? Safari and Opera are merely exposed to it in the same way IE is/was.

3 Posted by Mark Wubben on 2 April 2008 | Permalink

* may be caused by a glitch.

4 Posted by Marko on 2 April 2008 | Permalink

Right. I had a problem of my monitor turning itself on every now and then. The underlying reason was the same.

5 Posted by ppk on 2 April 2008 | Permalink

@mark: Such an OS glitch would also have to show up in Firefox, as well as older Opera's and Safari's. Therefore I think it's a true browser bug.

6 Posted by Robbert Broersma on 2 April 2008 | Permalink

If you want to have fun with mousemove oddities try using mousemove events on input fields.

7 Posted by David Storey on 2 April 2008 | Permalink

I didn't know about this change. I'll try to dg through our bug tracking system and see what caused it. As Saf and Opera both change, I can only think that major sites are relying no IE behavior, and not breaking it made those sites fail. If so then IE fixing it will help, except that now they have version targeting, the sites in question could go "arggh why is it broke in IE8", and use the version targeting, which will put the other vendors in a hard place - working to standards will break sites and not working to standards will break sites. while IE continues to work no matter. This is all theory however, but is one of the reasons I can't stand version targeting with a passion called hate.

8 Posted by ppk on 2 April 2008 | Permalink

@david:
>As Saf and Opera both change, I can only think that major sites are relying no IE behavior, and not breaking it made those sites fail.

Yes, that sounds likely. The problem is that I can't think of a situation in which you have to work around this bug. I mean, even if the mousemove event fires when the mouse doesn't move, the mouse position remains the same; and it's the mouse position that you commonly read out after a mousemove event.

Any extra information would be very helpful.

9 Posted by Markus Fischer on 2 April 2008 | Permalink

I came over this "Why do I get spurious WM_MOUSEMOVE messages?" (http://blogs.msdn.com/oldnewthing/archive/2003/10/01/55108.aspx ) lately, which is on the Desktop/OS level. But it looks like it's related.

Maybe FF works around it internally by comparing positions before passing it on?

10 Posted by ppk on 2 April 2008 | Permalink

Let's test this:

1) Please take IE5, 6 or 7, Safari 3.1 or Opera 9.5b and go to http://www.quirksmode.org/js/events/mousemove.html
2) Move the mouse for a while, then make it perfectly still.
3) Please leave a comment if IE does NOT fire extra, buggy events. Please note your OS.

11 Posted by Kit Grose on 3 April 2008 | Permalink

Actually Safari 3.1 (Mac) doesn't appear to trigger mousemove events for me on your test page when it's stationary EXCEPT in the case where I press a key (even a meta key without any page action like the command key), where it triggers both document and window mousemove on keydown, and again on keyup.

12 Posted by Tino Zijdel on 3 April 2008 | Permalink

I'm also not convinced that this is a case of Opera/Webkit emulating (old) IE since I can not think of any compelling reason to do so. You might want to ask Opera or the Webkit team; they're generally more willing to share information than Microsoft is ;)

I personally don't think it's wise for other browservendors to continue to mimic IE <= 7 behaviour for cases where they don't already do so; future reverse-engineering should be based on IE8 and only for cases where existing standards don't explicitly define UA-behaviour (and even then caution should be made, I am f.i. totally displeased with the Firefox 3 new table layout algorithm which is based on IE's algorithm).

The biggest problem however in all this is the fact that Microsoft isn't working together with the other browservendors /at all/. Even though they're participating in several W3 WG's their constructive activity is almost nill. They f.i. selectively implemented parts of HTML5, with changes and own additions, without ever having notified or consulted the WG. Even with Chris Wilson as co-chair of this WG, who hasn't even delivered on the promised MS review of the WD which was due August of last year!

13 Posted by Anton Nekipelov on 3 April 2008 | Permalink

Windows XP SP2
IE7 does not trigger false events
S3.1 does not trigger false events

14 Posted by Lapalazala on 3 April 2008 | Permalink

IE7 XP SP2 didn't seem to trigger false events at first.

Then, after I went to get a cup of coffee, 4 new events appeared. I thought this could have been caused by my colleague bumping into the table a bit, but tests of pretty hard bumps didn't produce any events.

15 Posted by ppk on 3 April 2008 | Permalink

The plot thickens. It's true that all browsers that display the buggy behaviour are on the same computer, although FF3b5 is, too, and it doesn't display the bug.

I just retested Opera 9.50 AND Opera 9.21 on this computer, and both show the buggy behaviour *some of the time* (especially when the mouse is on the fringes of the test paragraph, it seems).

Gotta run now, but I'll likely return to this problem tonight. Meanwhile, if anyone wants to test this, please go ahead. I'm especially interested in Mac and Linux reports.

16 Posted by Alistair Potts on 3 April 2008 | Permalink

Seems to be connected to the OS redraw event (I'm using Vista)

Here's what I did:
With IE running on your test page, I fired up Task Manager (show proesses for all users) and sort by CPU usage. As Windows does its many things, all the rows have to be rejiggled in Task Manager every couple of seconds (or whatever the interval is).

And every time it redraws the Task Manager pane, then a mousemove fires in IE.

Hope that helps!

17 Posted by Json on 3 April 2008 | Permalink

I am running both FireFox 2 and IE6 on Xp Pro with all service packs installed.
I do not seem to get the mousemove on either, but then again I stopped waiting after a few minutes.
One thing I DID notice: When I used Alt-Tab to switch between browsers, IE DID report a mouse move even though I did not move the mouse _ I just changed the Windows that had focus using the keyboard

18 Posted by Venkman on 3 April 2008 | Permalink

IE7 (7.0.5730.13) on XP SP 2.
An old Dell mouse with a generic MS driver which doesn't let me fix the polling rate (in case it matters).

The problem doesn't appear to occur. I've waited for maybe a couple of minutes.

What does happen is that two mousemove events are fired every time IE gains or loses focus (using Alt-Tab, not the mouse, of course). And I mean 2 for gaining focus and 2 for losing it.
In fact, I got IE7 on the background (mouse over that window) and I'm writing this on Fx3b5, if I press the "context menu key" on the keyboard a mousemove event is registered in IE7, when I press Esc, another one.
If I navigate the context menu with my keys, everytime I open or close a submenu, a mousemove event is registered in IE's window.

Entertaining.

19 Posted by Peter Siewert on 3 April 2008 | Permalink

XPsp2 Pro
Could not reproduce issue in Opera 9.5 or IE 7.

Might the spurious events actually be comming from the mouse?
A test for someone how can reproduce the issue: if you swap your mouse for a different one (like an old analog ball mouse), does the frequency of the spurrious events change?

Some laser mice will occasionally send mouse events to the OS even if the mouse did not actually move.

20 Posted by Kevin Weibell on 3 April 2008 | Permalink

I have opened Firefox 3b5, Opera 9.26, Safari 3.1 and IE7 next to each other (WinXP32 SP2 and all updates). Even when the windows are inactive, they fire the events as soon as the mouse hovers over the window.

Alt+Tab is indeed interesting: While Firefox doesn't show any strange behaviour, while Safari, Opera and IE do.
If the mouse is placed inside the window (document, not the toolbar), then a mouseover event is fired once in this browser when hitting Alt+Tab, even if it is not the currently focused window. The event is fired again when releasing Alt+Tab, no matter which window is now active. This does not always happen in Opera though (why not? Could not reproduce yet...)

21 Posted by David Storey on 3 April 2008 | Permalink

I've talked to a few people in Opera, and they don't know of any change, so I can only think it is either a hardware issue, an accidental regression or a long term bug that didn't show up for you in Merlin.

22 Posted by Wayne Pan on 7 April 2008 | Permalink

Here's something interesting:

OS X 10.5.2
Safari Version 3.1 (5525.13): mousemoveon events fire for document and window on keydown and again on key up if Safari is in focus.

However, for Firefox 2.0.0.13 on the same computer this does not happen. But it does happen when you cmd-tab back to FF2. Odd indeed.

23 Posted by Nano. on 7 April 2008 | Permalink

I have seen also the triggering of the event once the Ctrl-Tab combination keys are pressed. IE7 Windows XP. But I think that even if the event is misleading triggered, if the coordinates of the mouse do not change, then we can trace it at the script level and behave correctly. Just my two cents.

24 Posted by Susan Shepherd on 9 April 2008 | Permalink

I tried your test and there wasn't anything buggy. But I got to your site since my mouse sometimes has a mind of its own, there are even times when the page I am writing at is moved downward as if someone was reading it in remote. I thank you for your blog since maybe it is a bug...BTW I am using a Windows XP OS