Fixed extra mousemove events on Windows caused by certain apps, not users

[download13]

Some platforms produce frequent mousemove events whether or not the mouse has moved. This causes the UI to always be displayed since userActive_ is always true. By keeping track of the last mouse position and only firing if the new position is different, we can eleminate the event spam.

[mmcc]

Thanks for the PR! Would you mind telling us a little more about when you see this happen (like what platforms specifically)?

[download13]

I got this in node-webkit on Windows 7 x64. I remember running across the same problem in Chrome a while back (not involving video.js) but didn't think much of it. There's an SO question where someone suggested it might be caused by applications attempting to prevent a power-saving state.

[gkatsev]

Another thing that will help is using requestAnimationFrame rather than setTimeout/setInterval for getting useractivity.

[heff]

@gkatsev, requestAnimationFrame is IE10+, so I don't think we could use that?

[gkatsev]

You'd want to use the polyfill which is basically requestAnimationFrame || webkitRequestAnimationFrame || mozRequestAnimationFrame || function(fun) { setTimeout(fun, 1000/60); }. http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/
So, in browsers that support it, it'll use rAF, but otherwise continue using setTimeout.

[heff]

Have you had a chance to test this in IE8?

[heff]

I'm a little cautious about this one for a few reasons:

1. This is clearly a bug in the platform where it's happening. There's no logical reason a mousemove event should be triggered when the mouse doesn't move. Which means there should be a bug report on the specific system. I found mousemove event gets fired for no reason nwjs/nw.js#1014, which says this is a Parallels issue, and makes me want more confirmation that we should be solving this. @download13, were you using this in parallels?
2. This is the first and only time this issue has been mentioned. There's nothing wrong with that in general, it's just easier to make a case for merging when at a least a few people are experiencing it.
3. It adds extra processing to the mousemove event which happens very rapidly. Though it's a single conditional, so it's not too heavy.

It would be nice to get ahead of this issue if it's going to come up again, but I'm not yet convinced it will. @download13, would it be possible to set up an example case where others could see this happening?

[download13]

The platform was node-webkit on Windows 7 64bit. No parallels or any other virtualization layer.

After more googling and testing, it turns out this is a bug that occurs when the task manager is open. Some other applications (iTunes and Windows Media Player) seem to cause it as well.

For an example, go to the videojs home page in Chrome and put the player into fullscreen mode. The controls should disappear after a short time. Now open task manager (assuming you're on Windows, haven't tested this with a mac but you could try opening iTunes) and again fullscreen the video. The controls should remain visible.

You can run this in the console to see the extra events:

addEventListener('mousemove', function(e) {
    console.log(e.type, e.x, e.y);
}, false);

From what I can tell, Firefox already filters out the extra events. Chrome and node-webkit fire the extra events. IE 11 does as well, but it doesn't seem to matter at the moment since fullscreen doesn't work there.

[heff]

I can confirm this happens with the task manager open. Windows Media Player didn't, but my VM has an audio issue so I wasn't able to see if something has to be playing.

So I think pulling this in is fine then, but I'd still like to be able to track a Chrome bug so we know if/when we can remove this. Would you mind submitting a bug to the chrome tracker about this?
I put together this jsbin you can use as an example. http://jsbin.com/ruzofamo/1/edit

[download13]

Submitted to chrome tracker

[heff]

Awesome, thanks. Pulling in.