Ignore the bug number on this mochitest, but apply the patch and run the test and you'll see that most of the time (at least in my build) the status fader stays active at the end of the test. The user isn't trying to do anything, the video is paused and all data is loaded. The status fader activation condition is if (this.video.seeking || this.video.error || (this.video.paused || this.video.ended ? this.video.readyState < this.video.HAVE_CURRENT_DATA : this.video.readyState < this.video.HAVE_FUTURE_DATA) || (this.timeUpdateCount <= 1 && this.video.readyState < this.video.HAVE_ENOUGH_DATA && this.video.networkState >= this.video.NETWORK_LOADING)) this.startFadeIn(this.statusFader, immediate); 'seeking' is false, 'error' is false, 'paused' is true and 'ended' is true, readyState is HAVE_CURRENT_DATA, but I think timeUpdateCount is only 1 --- there's a 'timeupdate' after the seek, but that's the only one. So the last clause kicks in and we display the fader because we think nothing much has happened and the video hasn't loaded yet. I don't think this should block or anything, but we should fix it.

I think possibly we should just check for timeUpdateCount == 0 here. There is no initial timeupdate (as per spec) so this should still be returning true when a video has just loaded and the user hasn't done anything.