Add resume and interrupt events on the MediaSession object

[xxyzzzq]

From @mounirlamouri on June 29, 2015 15:33

Ideally, we should allow MediaSession instances decide how to behave when they are resumed or interrupted. Exposing events that could be cancelled would help. This is particularly important for Web Audio for which the best a UA can do is to break the link between the producing source and the output device. A MediaSession instance might stop the producing source and resume it when needed.

In addition, the interrupt event could have information about the ducking behaviour.

Both events could have information regarding how and why the session was resumed/interrupted. For example, whether it happened from a user interaction.

Copied from original issue: WICG/mediasession#78

[xxyzzzq]

From @foolip on June 29, 2015 19:14

Yep, I agree that we should fire events for these state transitions. However, it does make it necessary to deal with the situation where a session is interrupted and in response the script does something weird like playing something else or calls preventDefault() without actually stopping playback itself. There's some relevant platform differences here. Android will happily let this kind of situation happen, while it looks like iOS will just mute the app but let it think that it's getting its way. Does that sounds right, @doomdavve?

[xxyzzzq]

From @doomdavve on June 30, 2015 8:50

Yes, the difference seems to be that on iOS apps can be muted by the system as dictated by the currently now playing app.

[xxyzzzq]

From @mounirlamouri on June 30, 2015 11:14

How detectable is that for the web page? Can we leave a door for the UA to ignore .preventDefault()? If my website is correctly written and I stop my audio processing and streams when the interrupt event is received and call preventDefault(), would the behaviour be any different between iOS and Android?

[xxyzzzq]

From @foolip on July 1, 2015 16:42

There is no issue for code that we would deem correct, all we have to contend with is accidental failure to pause primarily, deliberate abuse of such a difference seems less worrying, to me at least.

The way I see this, we ought to have a default behavior that pauses all participating media elements and mutes/suspends all participating audio contexts. So it comes down to whether or not the event is cancelable. I lean towards saying that at least the interrupt even should be non-cancelable, unless we can see some plausible use case that would justify the resulting incompatibility.