The cause is that when we try to resume playback during the phone call, we are not allowed because audio focus can't be used. As a result, we make inactive the media session. An easy fix is to instead keep the session suspended if it was suspended. However, because requestAudioFocus() is async, what happens is that the video player is playing for a short time and when it is paused, it is removed from the session.

When Spitzer happened, we decided to not worry about requestAudioFocus() being async because we expected failures to be rare. They are at ~1%. We might want to have a strong handling of these.

Hmm, definitely resume should work. Why is it removed from the session? It seems like as long as the session is visible it should maintain control ability over WMPI.

I don't think async was about failures being rare, at least to me, ISTR it being about failures not providing sufficient opportunity for audio blips between start and failure. I still expected the session UI to work and be interactive though.

Not sure what you mean by "resume should work". Resume should not work because the audio focus can't be taken. Because of this, the player thinks it was paused and a paused player is removed from the session.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot