1444541 - MediaRecorder goes to a stopped state when pulling out a tab

Status: VERIFIED FIXED

(Core :: Audio/Video: Recording, defect, P2)

Description

[Jeremy Noring]

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.

Comment 1

[ovidiu boca[:Ovidiu]]

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.

Comment 2

[Andreas Pehrson [:pehrsons]]

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

Comment 3

[Andreas Pehrson [:pehrsons]]

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

Comment 4

[Andreas Pehrson [:pehrsons]]

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?

Comment 5

[Andreas Pehrson [:pehrsons]]

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 6

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1444541 - Don't stop recorder on pagehide during frameswap.

Review commit: https://reviewboard.mozilla.org/r/228946/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/228946/

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8960179 [details]
Bug 1444541 - Don't stop recorder on pagehide during frameswap.

https://reviewboard.mozilla.org/r/228946/#review234824

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bcdb264028e9
Don't stop recorder on pagehide during frameswap. r=smaug

Comment 9

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/bcdb264028e9

Comment 10

[Andreas Pehrson [:pehrsons]]

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

Comment 11

[Julien Cristau [:jcristau]]

Comment on attachment 8960179 [details]
Bug 1444541 - Don't stop recorder on pagehide during frameswap.

media recorder fix for beta60

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2fee5cc3ec3a

Comment 13

[ovidiu boca[:Ovidiu]]

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.

Comment 14

[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!

Comment 15

[ovidiu boca[:Ovidiu]]

Thanks Jeremy for your reply.
Based on comment 13 and comment 14 I will mark this issue as verified fixed.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Looks like needinfo for me wasn't ever cleared.
(doing some end-of-the-year clearance on really old needinfos)