The first pass at video controls (bug 448909) landed without tests due to time constraints. We should at least have some basic tests to make sure video controls don't unexpectedly break. A couple of ideas: * async reftest to compare (!=) two <video> pages, one with a mouse event fired at it to trigger the display of controls. This would be very basic, but is also a good sanity check. The most common mistake I've made when working on the controls is a syntax or parse error that completely breaks the binding. Making sure the controls are there when expected (and gone when expected) is a good sign they're not majorly broken. * mochitests to fire mouse events at the controls, and ensure that the video state updates accordingly (playing, muted, seeked, etc) This is harder, and my experience with mouse events in other mochitests is that they can be fickle. :( There are also timing issues involved, which makes it more challenging to write tests that don't fail randomly. Internal state of the controls isn't readily available to the outside world, so it might be hard to target specific parts of the controls, or see if they're consistent internally.

I'd be interested in helping out with the mochitests, if you'd like.

(In reply to comment #1) > I'd be interested in helping out with the mochitests, if you'd like. Oops, somehow missed this until just now. Thanks but sorry! :)

Comment on attachment 349899 [details] [diff] [review] Patch v.1 [Checkin: Comment 6 & 7] Hrm, this can just be checked in, as it's only a test.

Verified this passes on OSX+Linux+Win, good to go.

Comment on attachment 349899 [details] [diff] [review] Patch v.1 [Checkin: Comment 6 & 7] http://hg.mozilla.org/mozilla-central/rev/09195bdb8ff7

Comment on attachment 349899 [details] [diff] [review] Patch v.1 [Checkin: Comment 6 & 7] http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8e5d3f6b0403

lotsa tests.