15:00:47 <RRSAgent> RRSAgent has joined #webrtc
15:00:51 <RRSAgent> logging to https://www.w3.org/2025/06/17-webrtc-irc
15:00:51 <Zakim> Zakim has joined #webrtc
15:00:51 <dom> RRSAgent, make log public
15:00:52 <dom> Meeting: WebRTC June 2025 meeting
15:00:52 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/Jun_17_2025
15:00:52 <dom> Slideset: https://docs.google.com/presentation/d/19txOdIoxN6SWEyeSyvE8mIkwzOSoejjG06xSOBayzZA/edit?slide=id.g2bb12bc23cb_0_0#slide=id.g2bb12bc23cb_0_0
15:00:52 <dom> Chairs: Guido, Jan-Ivar, Youenn
15:01:19 <dom> Present+ Harald, Guido, Dom, Youenn, TimP,  Jan-Ivar
15:02:06 <dom> Present+ Elad
15:03:22 <dom> Recording is starting
15:04:01 <dom> Present+ KacperWasniowski
15:04:57 <dom> Present+ RichardBarnes, PeterThatcher
15:05:38 <dom> Topic:  Screen capture
15:05:38 <dom> Subtopic: -> https://github.com/w3c/mediacapture-screen-share/issues/321 getDisplayMedia: Distinct “Error” for Cancellation
15:05:38 <dom> [slide 10]
15:06:50 <dom> [slide 11]
15:07:48 <dom> [slide 12]
15:07:58 <dom> [slide 13]
15:09:55 <caribou> present+ Carine
15:10:08 <dom> [slide 14]
15:11:06 <dom> [slide 15]
15:12:16 <dom> Jan-Ivar: this seems like a valid use case to solve, if all browsers implement transient activations
15:12:35 <dom> ... Firefox already returns a "NotFoundError" when hitting an OS limitation
15:12:58 <dom> ... in an iframe with a policy limitation, it does return NotAllowedError which might indeed be improved
15:13:13 <dom> ... [NB  a mistake with the constraint attribute on slide 14]
15:13:45 <dom> ... -1 on relying on prototype, would be preferable to have an additional attribute (e.g. boolean "userInitiated")
15:14:01 <dom> Youenn: could we use the Permission API to determine this already?
15:14:27 <dom> ... it tells you if the user persistently denied access - which would be the same situation if denied by iframe policy
15:14:40 <dom> ... I'm not sure if they need to be distinguished
15:15:00 <dom> ... I think NotFoundError + persistent denied should be sufficient
15:15:21 <dom> Elad: the permission API can't be used for this: it's asynchronous, and it requires asking all the time
15:15:49 <dom> Youenn: if the user has put a setting to always deny getDisplayMedia, it will not be "ask" again, it will be systematically "deny"
15:16:12 <dom> Elad: I don't think this is possible in any browser at the moment, not even sure it should be exposed
15:16:37 <dom> ... but that's an edge case compared to the majority of cases
15:16:58 <dom> ... the asynchronous nature of the permission API doesn't allow to tie a rejection to a specific call of getDisplayMedia
15:17:18 <dom> Youenn: the same issue exists with getUserMedia - what is specific to getDisplayMedia here?
15:17:50 <dom> Elad: getDisplayMedia() will always involve a new prompt - each call has its own state
15:18:03 <dom> ... getUserMedia can persist in a given session or even across sessions
15:18:53 <dom> ... likewise, usually a choice on denying camera is unlikely to be changed, whereas canceling a screen share can reflect a temporary decision
15:19:14 <dom> Youenn: not seeing a big difference between the two
15:20:19 <dom> Harald: you listed 3 sources of failures - that point towards a string rather than a boolean (e.g. "user-denied", "internal-failure", "os-disallowed")
15:20:44 <dom> Elad: I tried this with mute reason before, but this wasn't too well received, hence I'm focusing on the narrowest need
15:21:32 <dom> Jan-Ivar: +1 to solving the use case; no strong opinion on the approach, but Youenn's point made sense to consider
15:22:36 <dom> Elad: the spec doesn't give any suggestion for persistent denial at the moment
15:23:25 <dom> Jan-Ivar: the Permission API allows to add a track handler which could probably solve this
15:24:01 <dom> Guido: the normal behavior is "always ask" - right after "deny" it becomes "ask" again
15:24:34 <dom> Jan-Ivar: it would have to be set to ask for all situations that aren't user initiated
15:25:06 <dom> Elad: that would still it a lot more complex than integrating it in the error message
15:25:24 <dom> Jan-Ivar: but there is value in not shipping new API surface
15:26:01 <dom> TimP: not convinced that synchronous handling is needed in the examples you gave (stats, prompt strategy)
15:26:44 <dom> Elad: one example: getDisplayMedia called from a button - should that button stay disabled while checking the permission state?
15:26:57 <dom> TimP: doesn't feel like a hard requirement
15:27:34 <dom> ... I think the simplicity argument is more compelling
15:28:33 <dom> Harald: I don't how Youenn's suggestion would work
15:29:12 <dom> Youenn: let's explore on github what use cases can or cannot be addressed with the two approaches
15:29:33 <dom> ... we need to see which situations would be distinguishable based on permission/error type
15:30:13 <dom> Guido: synchronicity is needed for correctness checking
15:30:33 <dom> RESOLVED: continue discussion on github issue
15:31:21 <dom> Subtopic: Expose capturer/capturee overlap
15:31:21 <dom> [slide 18]
15:32:48 <dom> [slide 19]
15:34:05 <dom> [slide 20]
15:35:29 <dom> [slide 21]
15:35:30 <dom> [slide 22]
15:36:00 <dom> [slide 23]
15:36:45 <dom> [slide 24]
15:37:38 <dom> [slide 25]
15:38:27 <dom> Youenn: in the example with the PiP, the Web app would like to know the current situation and what would happen with PiP
15:38:48 <dom> ... PiP might trigger an overlap of its own
15:39:18 <dom> Elad: I'll cover this when describing proposal #2
15:39:29 <dom> ... but note that PiP is only one of the situations you want to manage
15:39:50 <dom> ... the first question would be whether PiP has any chance to be useful - which it can't be if there is no overlap at all
15:40:14 <dom> [slide 26]
15:41:36 <dom> [slide 27]
15:41:39 <dom> [slide 28]
15:42:16 <dom> Jan-Ivar: leaving aside our current open position on document PiP
15:42:34 <dom> ... this feels like a good use case
15:43:20 <dom> ... re proposal 1, could we expose only the percentages instead of the values needed to calculate them?
15:43:52 <dom> Elad: the absolute values can be recovered from the percentages
15:44:11 <dom> Jan-Ivar: but conversely requires exposing fewer attributes
15:44:24 <dom> Elad: I can live with either approaches
15:45:16 <dom> Jan-Ivar: re initial vs dynamic (slide 28), making it dynamic could lead to the browser fighting with the user
15:45:29 <dom> Elad: this would be a readonly value
15:45:46 <dom> Jan-Ivar: but there could be a fight via PiP
15:46:36 <dom> Elad: there is no such mechanism at the moment for the Web app to control the position of the PiP, and if there was, the problem would exist independently of exposing that dynamic data
15:46:49 <dom> Jan-Ivar: I think starting with starting with at "opening" time would be safer
15:47:45 <dom> Elad: the only use case I can imagine is if the web app wants to offer a better layout based on determining dynamic values changing, but it's arguably hypothetical
15:48:20 <dom> ... some activity is already observable through the change of the captured window sizes
15:48:57 <dom> Jan-Ivar: let's focus on open for now, and discuss if/when to update the values
15:49:11 <dom> ... I'd support initialPercentage
15:50:07 <dom> TimP: I don't see anything problematic in terms of privacy
15:50:35 <dom> Youenn: percentage seems fine; I'm wondering whether a hint to the UA would be sufficient
15:51:24 <dom> ... Could you file an issue which would illustrate how the percentage would be used? sometimes what is overlapping is important
15:52:01 <dom> ... my primary concern is about managing focus rather than dealing with PiP
15:52:30 <dom> ... understanding the PiP use cases better would be important
15:52:49 <dom> Jan-Ivar: let's distinguish PiP as a remedy vs PiP as a source of overlap
15:53:24 <dom> Elad: the MVP for me is not to trigger PiP when disruptive, trigger it when it's clear it would help, and let web app developers explore the in between
15:54:42 <dom> RESOLVED: agreement on the validity of use case, continue discussion on to-be-created github issue
15:54:52 <dom> Topic: WebRTC: How to find the remote fingerprint?
15:54:52 <dom> [slide 31]
15:56:14 <dom> [slide 32]
15:57:13 <dom> [Elad departs]
15:57:17 <dom> [slide 33]
15:57:44 <dom> [slide 34]
15:58:46 <dom> [slide 35]
15:59:11 <dom> [slide 36]
17:13:24 <Zakim> Zakim has left #webrtc