I have a movie that is about 8 seconds long. If I play to movie then move the mouse out of the movie half way during play the video controls disappear as expected. When play stops I move the mouse over the movie and the scrubber shows the time as it was when the controls were hidden, not the actual ending time of the movie.

Can you post a link to the movie/testcase?

Seems to happen with all my movies that I tested which are just generated with ffmpeg2theora. An example is http://people.mozilla.com/~dtownsend/testcases/bug493523/Cog.ogg

I don't think the scrubber visibility really is causing it, it's the same issue as bug 481106. I've seen variability in reproducing that bug (probably due to exactly timing of timeupdate events), so that's probably what you're seeing.

Sorry, I read "doesn't show the correct time" as meaning the symbolic position, not that numeric time is literally incorrect. So, yeah, this is a different issue. I wonder if the <scale> is being too smart about suppressing updates when it's invisible, such that we never update the timestamp.

So, the code in nsSliderFrame.cpp is never calling CurrentPositionChanged() when the element is hidden, which means it never gets a chance to do the ValueChanged callback (which is how the videocontrols find out about the slider being changed, added by bug 472090).

I don't think we should block release on this.

Mossop pointed out we could just update the thumb when showing the controls, which wallpapers over the problem and is a simple fix. We can spin off the root problem to another bug to fix later?

Comment on attachment 378488 [details] [diff] [review] Patch v.1 I'd prefer it if you frobbed the scrubberThumb in doFade if you're transitioning between hidden and visible.

Perhaps it would be reasonable for the slider frame to post a valueChanged notification when it is unhidden?

(In reply to comment #9) > I'd prefer it if you frobbed the scrubberThumb in doFade if you're > transitioning between hidden and visible. doFade() and startFade() are generic routines for animation, so I kind of don't want to stick a special case in the middle of doFade. But I guess it would catch any edge cases with fading control in at other times. (In reply to comment #10) > Perhaps it would be reasonable for the slider frame to post a valueChanged > notification when it is unhidden? Yes, I think that's the root problem and this would be the idea fix. I'm not quite sure how to do that, so I'm suggesting we take this as a wallpaper fix for the looming 1.9.1 freeze, and fix it properly in a followup.

Updated patch.

Comment on attachment 378673 [details] [diff] [review] Patch v.2 >+ self.scrubberThumb.setTime(self.video.currentTime * 1000); Is it worth calling valueChanged("curpos", video.currentTime * 1000, false); instead?

Yes, yes it does. Nicely prevents the need for one chunk of the patch in bug 493884.

Comment on attachment 378692 [details] [diff] [review] Patch v.3 r=me by code inspection with the comment for fader.name fixed.

Comment on attachment 378692 [details] [diff] [review] Patch v.3 a191=beltzner Won't hold release for this, but should be super-safe. Make sure it bakes for a cycle on mozilla-central before you move it to 1.9.1

Pushed http://hg.mozilla.org/mozilla-central/rev/ab84f39da6c7

Pushed to 191: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/46eb50652f1d

Verified fixed on trunk and 1.9.1 branch with builds on all platforms: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090522 Minefield/3.6a1pre ID:20090522031102 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre ID:20090522030833 Can this be tested please?