There is a huge performance regression for video playback on nbcnews.com when HA disabled. Regression pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cea04d0eb7c9&tochange=f283941dbf75 Caused by either bug 795674 or bug 800287 STR 1. Install and launch nightly 2. Disable HA and restart 3. Visit http://video.msnbc.msn.com/rock-center/49377407/ 4. Notice that video is really choppy. 5. Compare with HA enabled.

This regression affects all pop-up video players on nbcnews.com

So this a problem only on Nightly, not Aurora?

(In reply to Boris Zbarsky (:bz) from comment #2) > So this a problem only on Nightly, not Aurora? Happened with latest nightly respin. I don't do my tests on Aurora, so not sure.

Turns out this regression requires Adblock Plus to reproduce. It occurs only if Adblock Plus is blocking content on the site and there are other content policy-enforcing extensions installed. With only Adblock Plus, no problems. With only RefControl, RequestPolicy, Redirect Cleaner, Greasemonkey, or Redirector, no problems. It's only when Adblock Plus is added to the equation that performance suffers. So then I wonder is bug 800157 is instead the cause of this regression.

Forget what I just wrote about the extensions. The whole Adblock Plus thing is an anomaly that is site dependent. On CTV News, with all add-ons disabled, I still get the issue: http://www.ctvnews.ca/video Thus, it is looking more and more like a possible regression from bug 800157. If someone could make a try, build without bug 800157, I can test and let you know.

After more testing, it turns out this bug is reproducible with a new profile and absolutely no customization, with http://www.ctvnews.ca/video It completely locked up Firefox and caused Flash Player to crash my graphics driver, forcing me to reboot. Thus, it does look like one of Matt's changes is responsible.

This sounds very much like the runfield regression reported in bug 795674 and should be fixed in the next nightly. However, that only covers video frames not being presented to the screen, reproducible display driver crashes should not be caused by this at all. Please file a new bug for the crash if it isn't resolved and is reproducible.

(In reply to Matt Woodrow (:mattwoodrow) from comment #7) > Please file a new bug for the crash if it isn't resolved and is reproducible. The crash is an adobe HA bug and seems to be some sort of timeout that causes my driver to crash -- something this bug is triggering. I will try out a build with bug 795674 once available.

Bug 795674 does generally fix the issue, but there is some odd lag in some circumstances, so maybe bug 795674 still has issues to address. I'll keep an eye on it. For now, I'll mark this as dependent on bug 795674.

(In reply to IU from comment #9) > Bug 795674 does generally fix the issue, but there is some odd lag in some > circumstances, so maybe bug 795674 still has issues to address. > > I'll keep an eye on it. For now, I'll mark this as dependent on bug 795674. Please re-nominate if there are still major perf issues after the landing of bug 795674.

Definitely much better, since bug 795674 landed. Currently not seeing anymore issues.

Opps

Bug 795674 was uplifted to Aurora.

IU, could you confirm this is fixed in F18 beta as well? http://www.mozilla.org/en-US/firefox/beta/ Looks of for me in beta 2 on Windows 7, but I couldn't reproduce the initial issue. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0

(In reply to Virgil Dicu [:virgil] [QA] from comment #14) > IU, could you confirm this is fixed in F18 beta as well? Yes it's fixed in Fx 18 Beta 3 And remains fixed in m-c nightlies as of cset 4e83d0987a31