1492261 - Closing the browser does not always end a call on Android

Status: RESOLVED DUPLICATE of bug 1382637

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

Description

[Dan Minor [:dminor]]

STR:
1. On desktop create an appear.in call, e.g. visit https://appear.in/dminor
2. On android, visit the same link
3. Once the call starts, press the square icon, and then the x on Firefox window
4. On desktop, it is still possible to see the camera and hear the microphone from the phone.

Expected results:

Closing the browser ends the call.

Opening the browser again and then closing it again causes the call to end as expected. However, the next time the browser is opened, the call will continue after it is closed.

Comment 1

[Dan Minor [:dminor]]

This is reproducible on https://mozilla.github.io/webrtc-landing/gum_test.html using either 'Video' or 'Audio' gUM. Since it reproduces with just audio, and we no longer use webrtc.org code for audio capture, this seems like it could be a problem with MediaManager or at that level.

Interestingly, if I open the gum_test page (or an appear.in call) in a second tab, and then close that tab, the capture ends as expected.

If I ssh into the phone, I can see that when this problem reproduces, the fennec process does not stop when I hit the X on the Firefox window. Opening the browser and then closing it again causes the process to stop.

It looks like shutdown works as expected when closing a tab, but something is causing it to fail when the browser is closed, and so the fennec process sticks around and continues to capture audio and video.

As mentioned above, if I'm on a call while doing this, the call does not end and the other participant can continue to see and hear the phone.

Comment 2

[Andreas Pehrson [:pehrsons]]

I'm gonna guess the shutdown blocker doesn't get triggered at [1]. Though that would indicate a bigger problem. Perhaps we manage to deadlock somewhere beyond that, but I hope not...


[1] https://searchfox.org/mozilla-central/rev/39cb1e96cf97713c444c5a0404d4f84627aee85d/dom/media/MediaManager.cpp#2302-2307

Comment 3

[Dan Minor [:dminor]]

I do see the shutdown blocker installed at [1] but not triggered at [2].

[1] https://searchfox.org/mozilla-central/rev/39cb1e96cf97713c444c5a0404d4f84627aee85d/dom/media/MediaManager.cpp#2311
[2] https://searchfox.org/mozilla-central/rev/39cb1e96cf97713c444c5a0404d4f84627aee85d/dom/media/MediaManager.cpp#2302

Comment 4

[Andreas Pehrson [:pehrsons]]

Does XPCOM shutdown [1] start? If so, where does it hang?

[1] https://searchfox.org/mozilla-central/rev/39cb1e96cf97713c444c5a0404d4f84627aee85d/xpcom/build/XPCOMInit.cpp#854

Comment 5

[Dan Minor [:dminor]]

(In reply to Andreas Pehrson [:pehrsons] from comment #4)
> Does XPCOM shutdown [1] start? If so, where does it hang?
> 
> [1]
> https://searchfox.org/mozilla-central/rev/
> 39cb1e96cf97713c444c5a0404d4f84627aee85d/xpcom/build/XPCOMInit.cpp#854

It appears not, but I'm hitting the limits of what I can debug by adding logging statements. I'm trying to get a proper debug environment set up.

Comment 6

[Dan Minor [:dminor]]

From what I can tell, XPCOM shutdown never starts.

If I set up breakpoints in XREMain::XRE_main in nsAppRunner, I can see mScopedXPCOM be allocated and initialized, and the call to XRE_mainRun(), but I hit no further breakpoints in that function, in particular I don't hit mScopedXPCOM = nullptr and I don't see ~ScopedXPCOMStartup run, which would call NS_ShutdownXPCOM and in turn ShutdownXPCOM.

So it appears that when you close fennec, normal shutdown does not occur, our shutdown blocker does not get called, and the media capture threads continue to run.

In this case where a tab is closed, we call MediaManager::OnNavigation [1] which shuts down the microphone as expected, which explains why that case works properly.

[1] https://searchfox.org/mozilla-central/rev/17f55aee76b7c4610a974cffd3453454e0c8de7b/dom/media/MediaManager.cpp#3524

Comment 7

[Dan Minor [:dminor]]

I have to admit I'm a bit out of my depth here. :snorp, I was wondering if you could have a look at Comment 6 and let me know if I've missed something or we should be handling shutdown differently on Fennec? Thanks!

Comment 8

[Dan Minor [:dminor]]

Or maybe :jya?

Comment 9

[James Willcox (:snorp) ([e-mail]) (he/him)]

This happens because killing an app via the task switcher does not cause the normal Android lifecycle events to trigger, so we have no opportunity clean anything up. Dylan has a possible solution for this with a similar issue in bug 1496684, so NI to him here.

Comment 10

[Andreas Pehrson [:pehrsons]]

Stumbled upon bug 1382637 and its dupes, which looks like the original for this issue. Closing this as another dupe of that bug.