1023175 - AudioContext should have attribute EventHandler onmozinterruptend/begin in the webIDL interface

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Comment 1

[Andrea Marchesini [:baku]]

Attachment: webaudio.patch

Comment 2

[(no longer active)]

These attributes are non-standard, so I feel a bit bad about just adding them here.  Can we just rely on addEventListener/etc for these events?  I'm curious to know what Olli thinks about that.

Comment 3

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

Well, if we have non-standard events (why?), adding those properties doesn't sound too bad to me.

Comment 4

[Andrea Marchesini [:baku]]

(In reply to Olli Pettay [:smaug] from comment #3)
> Well, if we have non-standard events (why?), adding those properties doesn't
> sound too bad to me.

Any audio component should notify the content code when it's muted from the AudioChannelService.
This happens for HTMLMediaElement and for WebAudio.

Comment 5

[(no longer active)]

Comment on attachment 8437599 [details] [diff] [review]
webaudio.patch

Andrea can you please reset the flag when this is ready for review?  Thanks!

Comment 6

[Andrea Marchesini [:baku]]

padenot, this patch introduces 2 new events in AudioContext: mozinterruptbegin and mozinterruptend. These 2 events are useful for b2g and they are dispatched when the AudioChannelService mutes the AudioDestinationNode because of some audio channel policy: https://wiki.mozilla.org/WebAPI/AudioChannels

These are not part of the webaudio spec and I would like to know if you have any interest to propose them for the spec. Or maybe there is already something similar.

I also would like to know what you think about adding this 'moz'-prefixed events in the webidl interface. At the moment these 2 events are already dispatched and they are available via 'addEventListener'.

Comment 7

[Paul Adenot (:padenot)]

(In reply to Andrea Marchesini (:baku) from comment #6)
> padenot, this patch introduces 2 new events in AudioContext:
> mozinterruptbegin and mozinterruptend. These 2 events are useful for b2g and
> they are dispatched when the AudioChannelService mutes the
> AudioDestinationNode because of some audio channel policy:
> https://wiki.mozilla.org/WebAPI/AudioChannels
> 
> These are not part of the webaudio spec and I would like to know if you have
> any interest to propose them for the spec. Or maybe there is already
> something similar.

Indeed, we are thinking about something relatively similar: https://github.com/WebAudio/web-audio-api/issues/317 (ability to suspend the AudioContext). This is something Google people need, and, in fact, we need that too (they have very legitimate use cases we already solved in a hackish way). I'll propose that to the spec (they don't have events for now, only two methods, start and resume), I'll keep the NEEDINFO as a reminder.

> I also would like to know what you think about adding this 'moz'-prefixed
> events in the webidl interface. At the moment these 2 events are already
> dispatched and they are available via 'addEventListener'.

That's fine. I think we like to put them in a separate section and label them clearly as "proprietary Mozilla extension", until they are specced.

Comment 8

[Andrea Marchesini [:baku]]

> Indeed, we are thinking about something relatively similar:
> https://github.com/WebAudio/web-audio-api/issues/317 (ability to suspend the
> AudioContext). This is something Google people need, and, in fact, we need
> that too (they have very legitimate use cases we already solved in a hackish
> way). I'll propose that to the spec (they don't have events for now, only
> two methods, start and resume), I'll keep the NEEDINFO as a reminder.

Good. Something important about this topic is this feature: bug 923247.
We don't expose AudioChannelService feature but just the AudioChannel and they can be muted based on their policy.

Ehsan, can you review this patch? The 2 events are already in a separated mozilla section of the interface.

Comment 9

[Andrea Marchesini [:baku]]

Comment on attachment 8437599 [details] [diff] [review]
webaudio.patch

It seems I need the review from a DOM peer. Smaug?

Comment 10

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

Question, why do we want to add a moz- prefixed thing? Why not without moz-prefix?
Assuming this stuff gets spec'ed.

Comment 11

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

Comment on attachment 8437599 [details] [diff] [review]
webaudio.patch

But since this isn't enabled by default, fine.

Are the events about muting the sound or about pausing?
The comment talks about "muted", but interrupt sounds like pausing.
Please clarify the comment.

Comment 12

[Andrea Marchesini [:baku]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/adce3575049d

Comment fixed. Thanks smaug.

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 14

[José Antonio Olivera Ortega [:jaoo]]

This bug blocks bug 1016277. It should be included in v2.0 release.

Comment 15

[Jason Smith [:jsmith]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #14)
> This bug blocks bug 1016277. It should be included in v2.0 release.

bug 1016277 is considered a feature though. In that case, this shouldn't block & should seek approval for 2.0.

Comment 16

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Jason Smith [:jsmith] from comment #15)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #14)
> > This bug blocks bug 1016277. It should be included in v2.0 release.
> 
> bug 1016277 is considered a feature though. In that case, this shouldn't
> block & should seek approval for 2.0.

IMHO bug 1016277 is a critical bug as two different apps using the telephony audio channel play audio at the same time.

Comment 17

[Jason Smith [:jsmith]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #16)
> (In reply to Jason Smith [:jsmith] from comment #15)
> > (In reply to José Antonio Olivera Ortega [:jaoo] from comment #14)
> > > This bug blocks bug 1016277. It should be included in v2.0 release.
> > 
> > bug 1016277 is considered a feature though. In that case, this shouldn't
> > block & should seek approval for 2.0.
> 
> IMHO bug 1016277 is a critical bug as two different apps using the telephony
> audio channel play audio at the same time.

I would call that bug feature work because it's the feature work required to get privileged access for telephony. We shouldn't have flipped the switch for privileged access for telelphony actually until that was fixed, but it's too late to change that now.

Comment 18

[Andrea Marchesini [:baku]]

Comment on attachment 8437599 [details] [diff] [review]
webaudio.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1016277
[User impact if declined]: multiple telephony calls can play audio at the same time.
[Describe test coverage new/current, TBPL]: fully covered.
[Risks and why]: None
[String/UUID change made/needed]: None

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/5784bfcffa5e