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.)
If you like this blog, why not donate a little bit of money to help me pay my bills?
Comments are closed.