Last Comment Bug 662589 - [Mac] YouTube videos freezing when player controls animates
: [Mac] YouTube videos freezing when player controls animates
async plug-in regression?
: regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: x86 Mac OS X
-- normal (vote)
: ---
Assigned To: Benoit Girard (:BenWa)
: Benjamin Smedberg [:bsmedberg]
: 662569 (view as bug list)
Depends on:
Blocks: 598425
  Show dependency treegraph
Reported: 2011-06-07 11:36 PDT by d.a.
Modified: 2011-07-14 07:46 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image d.a. 2011-06-07 11:36:14 PDT
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0a1) Gecko/20110607 Firefox/7.0a1
Build Identifier: 

I believe this started when bug 598425 landed. 

Whenever the volume control or the seeker bar animated the video will freeze for a fraction of a second or so or the FPS will drop slightly depending on the video.

Reproducible: Always

Steps to Reproduce:
1. Goto
2. Let the video load a bit.
3. Mouse over the player so the seeker bar expands while the video is playing

Running latest nightly of Firefox and latest Flash version ( on a MacBook Pro (Late 2008).
Comment 1 User image Steven Michaud [:smichaud] (Retired) 2011-06-07 11:44:36 PDT
I assume these problems don't happen with the last mozilla-central nightly that didn't include the patch for bug 598425 (dated 2011-06-05) ... or do they? :-)
Comment 2 User image d.a. 2011-06-07 11:52:57 PDT
Playback is smooth with nightly from the 5th, playing it with nightly from the 6th and 7th causes the freezing.
Comment 3 User image Benoit Girard (:BenWa) 2011-06-09 09:02:07 PDT
*** Bug 662569 has been marked as a duplicate of this bug. ***
Comment 4 User image Benoit Girard (:BenWa) 2011-06-09 09:06:45 PDT
What's happening is while the bar resizes we get invalidate rects only for the playback bar when we should be getting it for the bar+video region. There several similar instances where only a sub region of what is changing will repaint because we receive the wrong rect from the plugin.

The fix here is to either (1) always redraw everything at the cost of performance or (2) file bugs with the plugins.
Comment 5 User image Benjamin Smedberg [:bsmedberg] 2011-06-09 10:06:10 PDT
You're sure that we don't get *separate* invalidates for the bar and the playback region, and we're just not making the region union correctly?
Comment 6 User image Steven Michaud [:smichaud] (Retired) 2011-06-09 10:30:54 PDT
For what it's worth, I can reproduce this bug.  I mention this because
I haven't been able to reproduce a couple of other bugs that have been
reported on the patch for bug 598425 (bug 662347 and bug 662843).

I tested with the firefox-2011-06-05-03-mozilla-central and
firefox-2011-06-06-03-mozilla-central nightlies on OS X 10.6.7 running
on a 2.5-year-old MacBook Pro.  The second of these two nightlies is
the first that contained the patch for bug 598425.  I only saw the bug
with the second nightly.
Comment 7 User image Benoit Girard (:BenWa) 2011-06-09 10:43:59 PDT
Benjamin is correct, I union the rect incorrectly as I misunderstood the API call.

I don't see the problem on a local build, but I see it on nightlies. I believe flash may be asking for a different rendering model (is it looking at the UA here?). Taking a quick look at this before I post a patch, since it will help me test.
Comment 8 User image Benoit Girard (:BenWa) 2011-06-09 12:46:26 PDT
Actually the api usage was correct. I compared the profile with about:support and could not find a difference. I now realized that about:support does not show when a new preference is added thus did not notice that I had set 'mozilla.plugins.use_layers' early on in testing. Filed bug 663187 about this.

Turns out that async rendering was not activated properly in the nightlies. I will post a patch shortly after it has been tested.
Comment 9 User image d.a. 2011-06-09 13:23:48 PDT
Setting mozilla.plugins.use_layers to true and I'm no longer seeing this bug. Also solved bug 618318 for me.
Comment 10 User image Benoit Girard (:BenWa) 2011-06-09 13:28:15 PDT
Thanks for the help debugging this problem. I hope to land a patch as soon as all the tests pass.
Comment 11 User image Jeff Muizelaar [:jrmuizel] 2011-06-21 22:54:00 PDT
Comment 12 User image Benoit Girard (:BenWa) 2011-06-22 17:14:37 PDT
(In reply to comment #11)
> Ping?

Pong. Did I miss a question?

The problem will be resolved once bug 610441 lands.
Comment 13 User image Asa Dotzler [:asa] 2011-07-07 14:43:32 PDT
The async painting is is off by default on Aurora and we're not likely to enable it so minusing for tracking.
Comment 14 User image Benoit Girard (:BenWa) 2011-07-14 07:03:12 PDT
I landed the changes to bug 663259. Async plugin should be on by default and this bug should be fixed. Does someone care to verify?
Comment 15 User image d.a. 2011-07-14 07:40:28 PDT
I can no longer see this, nor the flickering described in bug 663259. I do however still experience bug 618318, however not as severe as before async plugins landed.

Note You need to log in before you can comment on or make changes to this bug.