This bug was filed from the Socorro interface and is report bp-8dee4f03-3cda-4cc8-82cb-a40292130903. ============================================================= On my dad's one-year-old Win7 laptop with integrated graphics (see crash report for system info), I see these symptoms: STR: 1. Go to URL -> Flash video and audio play smoothly 2. Click video to pause -> video and audio pause 3. Click again to unpause -> audio resumes smoothly, video @ 1 frame/several secs (!) 4. Moving the mouse -> video refresh speeds up significantly, looks ok 5. Stop moving mouse -> video @ 1 frame every several seconds, audio ok Note: Above also happens with yesterday's Nightly build. This report is primarily about above symptoms. In addition: 6. (Crash happened once:) Click around, resize window, unknown action -> crash See crash-report (happened only on FF23, not Nightly) - Even if crash is not reproducible, I linked the report as the system info may be useful. The laptop's CPU is visibly strained in Task Manager during this. But comparatively, Google Chrome does not exhibit these symptoms on same laptop with same site, and the mouse movement workaround points to logic error not performance issue. Believed observed on other web sites like youtube as well. Not able to reproduce on second more powerful desktop Win7 machine.
Chrome uses a custom, built-in, Flash. A better comparison would be Chromium, Opera (or Chrome configured to not use the built-in Flash). Can you confirm with those? It sounds like a Flash issue, but if it's still limited to Firefox, could you provide a performance profile for the situation so we can see if something in Firefox stands out? https://developer.mozilla.org/en-US/docs/Performance/Reporting_a_Performance_Problem
Chromium crashes immediately on the URL FWIW: Problem signature: Problem Event Name: APPCRASH Application Name: chrome.exe Application Version: 31.0.1607.0 Application Timestamp: 5214b148 Fault Module Name: StackHash_812f Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Code: c000041d Exception Offset: ffffffffeab5becc OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 812f Additional Information 2: 812f75858e9f17048e833ca76ffa548d Additional Information 3: 15cd Additional Information 4: 15cdbb2aac0cebfe5d07422057fe9fd5 At least we're doing better than that. :-) We didn't try to reconfigure Chrome to test there yet. We did two performance profiles in Nightly: 1. http://people.mozilla.com/~bgirard/cleopatra/#report=29b883047198272834d8aeecbc2ea63c95733075 This one follows the STRs and was taken 10 seconds after the video refused to unfreeze. We had video turned off in Skype while doing this (I'm remote from my dad who was doing the test so we still had Skype audio). Turns out Skype accounted for a lot of the CPU usage I mentioned earlier, but my dad says he's observed this problem without Skype, so CPU usage may not be to blame. We had some problems getting a good profile, because the Ctrl+Shift+O analyzer shortcut didn't work for my dad (he's on a Norwegian Windows installation, and even with English keyboard layout nothing happened, caps-lock was off), which made it hard to analyze because as the symptoms above mention, the video tends to start again as soon as he moves the mouse, so getting to the gecko profiler dropdown to push "Analyze" button was tricky. He believes the video was frozen during this profile, though it is of course possible it froze for other (bandwidth) reasons. On some of the attempts right before this profile, he says the video looked tried rapidly to catch up to the audio as soon as he moved the mouse. As you can see, very little CPU is used, which may suggest a logic bug. 2. http://people.mozilla.com/~bgirard/cleopatra/#report=e166a48f534f4e608d7cf2783ebdb4c0f9e5305c We caught this slightly different symptom while trying to reproduce further. Same session, repeating STRs. This time, at the moment of clicking to unpause, we both saw (I saw on his shared screen through Skype) a dramatic jump to near-100% CPU on all four virtual cores shown in Task Manager (which was floating ontop). The 100% CPU persisted for 10+ seconds, so we grabbed a profile of it. At the same time I saw Nightly show a "script is not responding" dialog, but it seemed to go away by itself? (The profiler tab opened so I couldn't tell) - We'd seen this only once before but left it out of the report until now. I decided to included it now since we have the profile. FYI. It may be a separate bug. Please let me know if you need more info.
Tested this with Chrome using non-built-in plugin (NPSWF31_11_8_800_94.dll) and it worked fine, which points to a problem in Firefox. Some more information (using Nightly, though this happens on 23 as well): - Using the STR URL, when he leaves the flash video alone, it runs fine - If he manipulates playback by clicking on it or using progress bar then the video usually freezes and sticks until he moves his pointer (He uses trackpad on laptop, so it happens a lot) - He was able to reproduce Bug 907402 twice (though not consistently) - The 100% CPU problem seems separate and happens less frequently. Crash even more so. The fact that moving the mouse cures it, points to input-event starvation, likely a broken interval timer. On a hunch, we tested "Bug 907402, setInterval stops firing callback", and we were able to observe it twice on his system. I've verified that the http://psfil.tv.nrk.no/pakke62/1.1.4986.22825a/scripts/_min/modules/player.min.js uses setInterval(). Incidentally, getPosition() in that same file is the cause of the CPU panic in the second performance profile in comment 2, if you dig down (I speculate that after some amount of setInterval starvation plus other input, it can mess up the script's logic, and cause it to free-run). I now think this freeze problem is caused by Bug 907402. I think this is a serious problem that may be causing video freezes on an unknown subset of systems, something users may even ditch Firefox for Google Chrome over (my dad is now on Chrome because he uses his laptop for all TV watching).
(In reply to Jan-Ivar Bruaroey [:jib] from comment #0) > 3. Click again to unpause -> audio resumes smoothly, video @ 1 frame/several > secs (!) Note that the video may have just frozen here, as my dad said it took a good 10 seconds before the next frame appeared in that particular case when I originally wrote the description. More recent tests seem to indicate the video freezes up until some form of input happens, rather than suffering a sustained degraded playback rate.
I've now observed this symptom in person on my dad's laptop. When watching something like http://tv.nrk.no/serie/morgennytt/nnfa07112513/25-11-2013 the video plays fine until I click on the video to pause it and click again to resume. When it resumes, the audio resumes but the video gets stuck for 12+ seconds, unless I move the mouse pointer, at which point the video speeds up real fast for half a second and then plays for a bit, until I no longer move the mouse then it gets stuck again. So I have to keep moving the mouse for it to play. Real annoying. Audio seems fine. Some new information: 1. I found a workaround: If I activate a different tab and then back to this tab then it fixes it and the video plays fine. 2. I see another problem which I think might be related. On the same laptop, when I go to Help/About Firefox and there's a newer nightly available, then the download spinner and the download tends to get similarly stuck! When I move the mouse then it continues. Note sure what is going on on this PC.
See also bug 937306.
I tested using the 25.0.1 candidate in Bug 933733 comment 40 with mixed results. On the upside, it seems to fix the problem with Youtube. Without this candidate (older Nightly), I experience the same problem on youtube as I do with flash video @nrk.no, which today is that about 1-5 seconds after I unpause playback without moving the mouse, the video freezes (audio continues), and after another 10 or so seconds the browser window minimizes itself (audio is still fine). When I unminimize it, I see it playing fine. On the downside, it does not fix the same problem with flash video @nrk.no. i.e. I experience the problem described above even with the 25.0.1 candidate. Lastly, I should note a small difference between youtube and nrk.no that I'm seeing, which is that at nrk.no, I see a dialog box for a split second right as the window minimizes itself. I caught it in a screengrab after a few trys: Shockwave Flash may be busy, or it may have stopped responding. You can stop the plugin now, or you can continue to see if the plugin will complete. In the above case, I did not move the mouse. Any time I move the mouse during the above freeze, then the video starts moving as long as I move the mouse, but the relief is temporary and it reverts to the symptom as soon as I stop (freeze followed by inevitable minimize).
This appears to be a top trending problem in https://metrics.mozilla.com/protected/sentiment/version/27 : Representative comments (Hover over the first one, "Flash"): "Please, please, please fix the youtube videos freezing. I have Windows 7, Firefox 27, Flash Player 18.104.22.168. The only way I can keep the videos playing is to continually move the cursor inside the video window." This matches my personal experience: It's the lone reason my dad doesn't use Firefox ("can't watch TV"). The report assures "We are actively collecting data and looking for partners throughout the organization to help figure out ways to investigate and mitigate this type of issues." - Well, I'm here! ;-)
I saw the blocking bug was closed as fixed here, so I contacted my dad to see if he could still reproduce this bug and the symptoms have changed. Pausing and un-pausing now works, however, just watching the video normally is now problematic, because the video inevitably freezes after a period of time between several seconds and a minute or so. When it freezes the picture is stuck while the audio continues. Move the mouse just a bit and the video starts moving again from where the audio is (the audio works throughout), and everything seems fine, until it happens again. Depending on how one watches shows, this is worse than before.
(In reply to Jan-Ivar Bruaroey [:jib] from comment #9) > > Pausing and un-pausing now works, however, just watching the video normally > is now problematic, because the video inevitably freezes after a period of > time between several seconds and a minute or so. When it freezes the picture > is stuck while the audio continues. Move the mouse just a bit and the video > starts moving again from where the audio is (the audio works throughout), > and everything seems fine, until it happens again. > This exactly explains my symptoms except that I'm on linux(gentoo) without any flash(or other plugins enabled; but I do have extensions) on firefox 40.0.2 (the previous version, 39.0.3, was and is working fine, retested just now by reinstalling the backed up binary-package). (also, probably irrelevant, pausing/unpausing didn't always work even in 39.0.3 - it pauses then plays again most of the time even though I only do 1 LMB click on the video, but maybe this is because I'm running inside a virtualbox instance(hostOS is linux manjaro) - but I can pause with pressing Space afterwards or LMB on the pause button on the youtube player) Disabling acceleration had no effect. (I tried searching for the linux version of this issue to no avail; that's why I'm posting here, maybe someone could guide me to where I should be posting... )
I can confirm that setting layers.offmainthreadcomposition.enabled to false (in about:config) fixes this for me: no more video freezing requiring key/mouse input to unfreeze. (browser restart required to take effect!) Tested on video: https://www.youtube.com/watch?v=uvTWxrLzHZU Credit: the only comment I read from here https://bugs.gentoo.org/show_bug.cgi?id=558150#c10 Thanks all.
For linux problems in fx 40 see bug 1193520.
I'm closing a lot of bugs which are filed as Adobe Flash bugs which are either irrelevant, not actionable, or not serious enough to track in the Mozilla bug tracker. For the most part, Flash bugs should be filed in Adobe bugbase, and we'll only track a few highly-critical issues in the Mozilla tracker.