Created attachment 8843650 [details] Complete example + static image exporting MediaRecorder drops frames when the main window looses focus (e.g when we switch to an other tab). This looks like it has the same limitations as requestAnimationFrame about this. In the attached example, the canvas animation is ticked to an audioContext based timer (which is not limited by this focus issue). When we loose focus, the Recorder drops the frames, even when stream.requestFrame is manually called. However, if we call canvas.toBlob(), we can see that all the frames are presented and rendered on the canvas, but somehow they're not passed to the recorder. Note : - Since chrome has fixed this bug (https://bugs.chromium.org/p/chromium/issues/detail?id=653548) it does work for them. - I am pretty sure it did work on beta channel around november of 2016, however I was unable to find a working release with moz-regression... A minimal version can be found here : https://jsfiddle.net/qnzz47pw/
Note, only the fiddle in comment 0 reproduces for me (OSX). The attachment is always silky smooth, no framedrops! Furthermore, the fiddle problem seems e10s related. If I open a new non-e10s window then it works fine. I tried as far back as 2016-07-12 (which is as far as mozregression successfully run builds for me for some reason), which puts it at 51, and with e10s it's broken, and with non-e10s it works. This might explain why you saw it working in a beta, but couldn't find a regression range. The Chrome bug you reference seems different, not producing any frames at all.
Has STR: --- → yes
Priority: -- → P1
Summary: (canvas.captureStream) Dropped frames in recording when the window is blurred → [e10s](canvas.captureStream) Dropped frames in recording when the window is blurred
Version: 54 Branch → 51 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yes e10s seems to be the trouble-maker. I disabled it and the number of dropped frames considerably lowered. (I still have some though) Also if I pointed to the not directly related chrome bug, it's because in their current stable version, this bug makes it impossible to test, while in canary, with shipped fix, we can see it works smoothly.
This is a P1 bug without an assignee. P1 are bugs which are being worked on for the current release cycle/iteration/sprint. If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.