MediaRecorder goes to a stopped state when pulling out a tab

VERIFIED FIXED in Firefox 60

Status

()

defect
P2
normal
Rank:
19
VERIFIED FIXED
2 years ago
Last year

People

(Reporter: jeremy.noring, Assigned: pehrsons, NeedInfo)

Tracking

Trunk
mozilla61
Points:
---

Firefox Tracking Flags

(firefox-esr52 wontfix, firefox59 wontfix, firefox60 verified, firefox61 verified)

Details

Attachments

(1 attachment)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36

Steps to reproduce:

I can reproduce this in both LTS release, and most recent version of Firefox.

1. Go to https://webrtc.github.io/samples/src/content/getusermedia/record/ on Firefox.
2. Click "Start Recording"
3. Pull the Firefox tab out into a separate window.


Actual results:

The MediaRecorder instance immediately goes to a stopped state, and fires the stopped event (check in the console log).  If you hit stop recording, you'll also see a console error because the MediaRecorder instance is in a stopped state.


Expected results:

The MediaRecorder instance should continue recording even when the tab is popped out into a new window.
I tested this issue on Mac OS X 10.12 with FF 59 release and FF Nightly 61.0a1(2018-03-13) and I see that something is not working right here. In my case the after I follow the steps from the description the "Start Recording" button becomes unactionable.
Status: UNCONFIRMED → NEW
Component: Untriaged → WebRTC
Ever confirmed: true
Product: Firefox → Core
Version: 58 Branch → Trunk
Rank: 19
Component: WebRTC → Audio/Video: Recording
Priority: -- → P2
I'm going to guess we trigger the code at [1]. Need to verify with MediaRecorder:4 logging.
Bug 969372 seems to have ... plenty of discussion as background for that code.

[1] https://searchfox.org/mozilla-central/rev/3abf6fa7e2a6d9a7bfb88796141b0f012e68c2db/dom/media/MediaRecorder.cpp#1704-1709
Indeed, I get this in the log when pulling the tab to another window.

> 2018-03-19 10:02:59.102185 UTC - [10918:WebRTCPD #1]: D/MediaRecorder Session.Extract 0x7f7d61359040
> 2018-03-19 10:02:59.102790 UTC - [10918:Main Thread]: D/MediaRecorder MediaRecorder 0x7f7d61304640 document IsActive 1 isVisible 0
> 2018-03-19 10:02:59.102876 UTC - [10918:Main Thread]: D/MediaRecorder MediaRecorder.Stop 0x7f7d61304640
> 2018-03-19 10:02:59.102941 UTC - [10918:Main Thread]: D/MediaRecorder Session.Stop 0x7f7d61359040
> 2018-03-19 10:02:59.103051 UTC - [10918:Main Thread]: D/MediaRecorder MediaRecorder 0x7f7d61304640 document IsActive 1 isVisible 0
> 2018-03-19 10:02:59.103097 UTC - [10918:Main Thread]: D/MediaRecorder MediaRecorder.Stop 0x7f7d61304640
> 2018-03-19 10:02:59.103224 UTC - [10918:Main Thread]: D/MediaRecorder MediaRecorder 0x7f7d61304640 document IsActive 1 isVisible 1
> 2018-03-19 10:02:59.109622 UTC - [10918:Main Thread]: D/MediaRecorder MediaRecorder 0x7f7d61304640 document IsActive 1 isVisible 1
> 2018-03-19 10:02:59.135518 UTC - [10918:WebRTCPD #1]: D/MediaRecorder Session.Extract 0x7f7d61359040
The decision to stop when not visible comes from bug 969372 comment 257, and I think from a concern of a document entering the bfcache and staying active, but to the user this appears as navigating away and stopping any recordings seems sane.

I'm surprised that pulling out a tab to a separate window would cause it to be hidden and then shown like this.

Perhaps the easiest fix would be to check `!doc->IsCurrentActiveDocument()` which is per the spec's "active document" and goes false when entering bfcache, instead of `!doc->IsActive() || !doc->IsVisible()`. But then I don't know near enough about these states to make that call. smaug, would you have any advice here?


The MediaRecorder spec doesn't seem to mention when the UA should automatically stop recording, except the hand waving of
> If the UA at any point is unable to continue gathering data for reasons other than isolation properties, it MUST stop gathering data (...)
and of course all tracks ending (from mediacapture-main and seems to apply to all MediaStreamTracks):
> (...) or because the User Agent has instructed the track to end for any reason) (...)

jib, would this be a hole in the spec?
Flags: needinfo?(jib)
Flags: needinfo?(bugs)
I traced the pagehide event to [1] and noticed a fix had been put in for a similar problem for HTMLMediaElement, bug 1191491. It's hopefully as simple as using that.


[1] https://searchfox.org/mozilla-central/rev/3abf6fa7e2a6d9a7bfb88796141b0f012e68c2db/dom/ipc/TabChild.cpp#2341
Comment on attachment 8960179 [details]
Bug 1444541 - Don't stop recorder on pagehide during frameswap.

https://reviewboard.mozilla.org/r/228946/#review234824
Attachment #8960179 - Flags: review?(bugs) → review+
Assignee: nobody → apehrson
Flags: needinfo?(jib)
Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/bcdb264028e9
Don't stop recorder on pagehide during frameswap. r=smaug
https://hg.mozilla.org/mozilla-central/rev/bcdb264028e9
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Comment on attachment 8960179 [details]
Bug 1444541 - Don't stop recorder on pagehide during frameswap.

Approval Request Comment
[Feature/Bug causing the regression]: Not a regression
[User impact if declined]: Pulling a tab doing a recording between windows will stop the recorder
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes, I just verified
[Needs manual test from QE? If yes, steps to reproduce]: yes, see comment 0
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Trivial change, and with this being early in the cycle it would be nice to get into 60 and ESR
[String changes made/needed]: None
Attachment #8960179 - Flags: approval-mozilla-beta?
Comment on attachment 8960179 [details]
Bug 1444541 - Don't stop recorder on pagehide during frameswap.

media recorder fix for beta60
Attachment #8960179 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
I verified this issue on Mac OS X 10.13, 10.12 and Windows 10 with FF Nightly 61.0a1(2018-03-23) and Beta 60.0b6 and I can't reproduce the issue described in comment 1. Please note that I couldn't reproduce the issue from the description. 

Jeremy, can you please download the latest FF Nightly from here(https://nightly.mozilla.org/) and try to reproduce the issue, it will help us, thanks.
Flags: needinfo?(jeremy.noring)
(In reply to ovidiu boca[:Ovidiu] from comment #13)
> I verified this issue on Mac OS X 10.13, 10.12 and Windows 10 with FF
> Nightly 61.0a1(2018-03-23) and Beta 60.0b6 and I can't reproduce the issue
> described in comment 1. Please note that I couldn't reproduce the issue from
> the description. 
> 
> Jeremy, can you please download the latest FF Nightly from
> here(https://nightly.mozilla.org/) and try to reproduce the issue, it will
> help us, thanks.

I tried it out and it works great.  Thanks so much for fixing this!
Flags: needinfo?(jeremy.noring)
Thanks Jeremy for your reply.
Based on comment 13 and comment 14 I will mark this issue as verified fixed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.