Meeting minutes
media-playback-while-not-visible permission policy
Gabriel: Proposal from Microsoft to create a new permission policy which, whenever set in an iframe, all the media in that iframe should be paused.
… An application might have an iframe that is very heavy and it may need to hide the iframe for a moment. Instead of destroying it, the app may want to pause the media so that it can resume things quickly afterwards.
… Any data in the iframe such as waveforms won't be lost when the iframe is hidden.
… That's the main goal. At Microsoft, Teams already uses that. We implemented a prorotype through the origin trial framework.
… Integrated with audio/video elements and also Web Audio AudioContext.
… Over the last year, we have been trying to find a venue for this feature to live on.
… I've joined meetings with Audio WG, Media WG, WHATWG about a year ago. At the time, groups did not feel they would be the right venue.
… Idea would be to incubate the feature in the WICG. Before I do that, I wanted to make sure that there's no interest in the Media WG.
… I'm raising this because Marcos showed some interest. Also heard positive feedback from Mozilla in an Audio WG meeting.
… I would prefer the feature to live in the Media WG.
cpn: I'd like to understand the interest to implement this generally speaking. What do implementers say?
Andy: Can't say for Webkit.
Dale: For me it seems obviously useful. Barring process praticalities, at Chrome we support this being in the Media WG.
Gabriel: When I talked with Paul last week, he told me that the best would be to discuss the feature here. Then spec change will go back to HTML.
… We may extend the feature to further scenarios such as viewport visibility. There is potential to expand.
cpn: An option here would be to create a WICG repo to work on spec text. I would assume that most of the text will end up being patches to other specs.
… It makes me wonder, from a practical point of view, about a WICG repo. I'm certainly happy to use the Media WG as the venue to discuss but I don't know that it can be a new deliverable for the Media WG.
… This may have some interaction with the Autoplay Policy Detection API.
… Does that sound like a reasonable thing to do?
Gabriel: That seems acceptable. To get a WICG repo set up for that, I'll need public support from other browser vendors.
Dale: That's a good way to go.
tidoust: What would you be looking for from the Media WG, e.g., IPR protection, or access to expertise? The group isn't well equipped to write the spec in this group as it touches on other specs
Gabriel: It's because of the proximity to autoplay detection feature. Maybe it could live in that spec? Having the spec in a WG rather than WICG makes it more permanent and well established
Francois: From the charter perspective, it's the scope that's the main consideration. The group could add more deliverables if it wants to. The scope would allow this feature
… I could check other if groups have done similar, ending up as patches to other specs
Dale: Is that unusual compared to other feature policy type features?
Gabriel: I remember Ian Clelland mentioned others are similar, in that it's not really a permission, but something frames are allowed to do, e.g., autoplay or wake lock
cpn: autoplay lives in HTML.
Gabriel: Could be a WG deliverable, if short lived. Would that be OK?
Francois: Happy to explore options. I'm wondering if it ends up being in HTML, we'd have to coordinate with WHATWG to check they're happy. WICG has connection to WHATWG
Dale: Get the consensus from other vendors, use WICG as venue. Then land the patches into other specs. Not sure there's a long term thing here for the WG
Chris: Agree
cpn: To summarize, proposed way forward: file standard positions with Mozilla/WebKit if not already done. With that, we can tie this to the WICG issue that you already raised. We can use the WICG to host the incubation on the text, and the Media WG as a venue to discuss.
Gabriel: Standard positions have been filed some time ago without responses.
cpn: I'm happy to help you get feedback.
Gabriel: If we actually get support from one of those, we can move forward, I believe.
cpn: I'll reach out to Paul and Marcos tomorrow.
Audio Session - Some websites misuse AudioSession type, preventing microphone access
Andy: I filed spec issue #46.
… To summarize, dscript.com is a podcast capturing web site. They adopted audio session some time ago. The bug was that their use of Audio Session completely breaks the ability to start the microphone on their site.
… The exception that we throw in Safari is not specified, I believe.
… At the very least, it would be useful to get more details.
… My larger concern was that it created a bit of a footgun. It is some evidence that the API is adding some burden on developers. It's not clear to me what the spec is trying to achieve by allowing developers to configure the type independently of getUserMedia.
… At least on Apple platforms, both the playback and playrecord types are meant for that.
… My question is whether playandrecord makes sense. If we think it is, the spec should be more explicit about the trade-offs, etc.
Tommy: This is more for Youenn than for me. I agree that the current state is not great, we're not making it clear that they are breaking things.
Andy: Talked with Youenn offline. I think Youenn is in a favor of aligning the spec and implementations.
… I may be leaning towards not having playandrecord type at all.
cpn: If you were to remove the type, what happens when you're capturing?
Andy: Underlying platform may have playandrecord, which may explain why it surfaced in the spec.
… But I don't think we need to align at the API level.
Dale: Chrome does not have plans to implement the Audio Session API for now.
… Resources are being redirected to AI these days, and feedback from developers also is more there. Priority for now is to keep things with a lot of usage running. That's the short term story.
alicia: Whenever you become more lenient with a spec in one browser, all the other browsers need to follow along.
Andy: And we only ship a subset of the specified Audio Session. I think we're still at the point where we can make updates without introducing major consequences for web sites.
… Audio Session API allows web sites to be more explicit about what they intend to be audible or in the background.
… We used to have heuristics.
Dale: We have heuristics too and haven't received complaints about that.
… I don't think users like the heuristics on desktop.
… I don't think the anger is for the Audio Session API, more about the choices that the platforms made.
Andy: Thanks for the feedback. Maybe my action item is to have another conversation with Youenn and have a more concrete proposal at TPAC.
cpn: I'm wondering about bringing Alastor in the discussion as well.
… I don't know how far along Mozilla are in terms of implementing this.
… I'm also happy to arrange a meeting at more friendly times for Youenn.
TPAC 2025 plans
Chris: w3c/
cpn: We've created an empty meeting schedule.
… We're asking you to add a "TPAC 2025" label to any of the issues and we'll add them to the agenda.
… If there are other things to consider, bring them to the main issue.
… Around mid-October, we'll get a draft agenda up.
… We have some issues labeled for Media Capabilities from Mark and some for EME from Xiaohan.
Chris: https://
cpn: Joint session with WebRTC, and then most of Friday for our specs.