The spec for media element playbackRate (see url) says any value is valid, except 0.0. nsHTMLMediaElement::SetAttr() should check for 0.0, and raise NOT_SUPPORTED_ERR exception if that comes in. Perhaps we should also ask the platform-specific decoders if they succeeded in changing the playback rate to the new rate before accepting the rate change? Some decoders may not be able to handle rate changes to certain values - for example, a negative playback rate in a progressively encoded media. Or maybe rather than throwing an exception if the decoder can't do a rate change, we should just not dispatch the ratechange event?

Bug 455500 fixes the check for 0.0 thing, and changes the tests from a todo to an ok to test the change. The issue about backends not supporting certain rates was raised on the whatwg mailing list and it's an issue that I don't think has been resolved. I'll check into it. In the meantime I think having the backend return NOT_SUPPORTED_ERR if they don't change the value and nsHTMLMediaElement passing that on seems a reasonable solution. What do you think?

Sounds OK to me.

Does it make sense to keep this bug open? We removed our skeletal support for playbackRate a while ago. The bug for implementing playbackRate (bug 495040) makes note of this issue, so I think we can go ahead and close this one.