16:01:06 <RRSAgent> RRSAgent has joined #webrtc
16:01:10 <RRSAgent> logging to https://www.w3.org/2025/01/21-webrtc-irc
16:01:10 <Zakim> Zakim has joined #webrtc
16:01:10 <dom> RRSAgent, make log public
16:01:11 <dom> Meeting: WebRTC January 2025 meeting
16:01:11 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/November_19_2024
16:01:11 <dom> Slideset: https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/
16:01:11 <dom> Chairs: Guido, Jan-Ivar, Bernard
16:02:01 <dom> Present+ FrederikSolengerg, Jan-Ivar, TimP, BernardA, PeterT, Tove, Harald, Guido, JasperHugo, Carine, Dom, PatrickRockhill
16:02:27 <dom> Present+ Elad
16:03:49 <dom> Present+ Youenn
16:04:06 <dom> Recording is starting
16:06:51 <dom> Topic: -> https://github.com/w3c/mediacapture-surface-control/ Captured Surface Control
16:06:51 <dom> Subtopic: Zoom control
16:06:51 <dom> [slide 10]
16:08:28 <dom> [slide 11]
16:09:17 <dom> Elad: implemented in Chrome like css zoom
16:09:21 <dom> [slide 12]
16:10:03 <dom> [slide 16]
16:10:20 <dom> [slide 13]
16:11:59 <dom> [slide 14]
16:12:18 <dom> Present+ Cullen
16:12:28 <dom> Present+ SunShin
16:12:46 <dom> Jan-Ivar: supports the attribute
16:13:03 <dom> ... there is a separate discussion about where the API should belong
16:13:13 <dom> ... instead of nullable, you suggest a default to 100?
16:13:48 <dom> Elad: re API anchoring, that discussion was around gestures, not for zoom level?
16:14:17 <dom> Jan-ivar: let's discuss the anchoring question later
16:15:14 <dom> ... although it would have been good to discuss this topic first
16:16:26 <dom> Cullen: could you tell more about how safe is this approach? given risks of overexposure
16:17:15 <dom> Elad: this has indeed been discussed - we're suggesting a layered security approach: the UA ensures the user gives consent to share a specific thing, plus additional consent on zoom/scroll?
16:17:22 <dom> Cullen: is the latter implicit or explicit?
16:18:24 <dom> Elad: this is in origin trial if you want to try - it comes with an explicit chrome level prompt
16:18:39 <dom> Cullen: I'll give it a try - it feels risky
16:19:02 <dom> youenn: attribute is an improvement; nullability allows to express whether zoomability has a meaning for the given surface
16:19:47 <dom> ... re API anchoring, we should discuss this; we had discussed in the past multiple surfaces captured in a single getDisplayMedia
16:20:27 <dom> ... we need to future-proof the API since that's one use case we know about
16:21:58 <dom> RESOLVED: zoomLevel is an attribute, nullable for now but may be revisited
16:22:40 <dom> Jan-Ivar: note that developers will need to test for undefined already since it's only available in one browser atm
16:23:07 <dom> HTA: there is a complexity cost to future proofing - I prefer designing for current requirement set
16:23:38 <dom> Subtopic: oncapturedzoomlevelchange
16:23:41 <dom> [slide 15]
16:23:43 <dom> [slide 16]
16:24:31 <dom> Youenn: feels like the event name is too long - we can bikeshed it later
16:24:38 <dom> Subtopic: getSupportedZoomLevels()
16:24:40 <dom> [slide 17]
16:26:01 <dom> s|get|get/set
16:26:03 <dom> [slide 18]
16:27:07 <dom> [slide 19]
16:27:42 <dom> [slide 20]
16:29:03 <dom> [slide 21]
16:29:59 <dom> Jan-Ivar: using Youenn's proposal allows to remove getZoomLevels(), which has risks of creating interop issues
16:30:22 <dom> ... also has nicer safety characteristics to avoid a malicious app to over-zoom
16:31:01 <dom> Youenn: +1 to the increase/decrease API; could you say more about the need resetZoomLevel()?
16:31:34 <dom> Elad: re removing the need of getZoomLevels, you still need it to know whether you've hit a max
16:31:53 <dom> ... we've heard the need for reset from product teams
16:32:22 <dom> Youenn: at least getSupportedZoomLevels() would only to report the extremes
16:32:55 <dom> Harald: setZoomLevel feels more ergonomic
16:34:02 <dom> Dom: you could return false to indicate that you've reached an extreme value
16:34:17 <dom> Elad: but that doesn't work when starting from the extreme
16:34:53 <dom> Elad: I'm hearing support to move forward with increase/decrease/reset, and simplify getSupportedZoomLevels() to a range
16:35:25 <dom> RESOLVED: Use increase/decrease/resetZoomLevel() and simplify getSupportedZoomLevels() to a range
16:35:45 <dom> Subtopic: Scroll control
16:35:45 <dom> [slide 23]
16:36:35 <dom> RRSAgent, draft minutes
16:36:36 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/21-webrtc-minutes.html dom
16:37:10 <dom> [slide 24]
16:42:40 <dom> Youenn: the costs for spec authors and implementers seem low
16:45:03 <dom> Elad: the implementation cost is not negligible
16:45:36 <dom> Dom: you could imagine applying effects on a local capture to e.g. visualize different color scheme on a design
16:46:02 <dom> Jan-Ivar: from a logical perspective, this is a one-to-many relationship
16:46:26 <dom> [slide 25]
16:48:21 <dom> Jan-Ivar: touch events would probably be applicable to e.g. windows tablets
16:48:31 <dom> ... for scrolling
16:49:02 <dom> [slide 26]
16:50:28 <dom> [slide 27]
16:51:06 <dom> [slide 28]
16:52:35 <dom> Youenn: forwardGestures(el, false) is pretty clear - not sure about the meaning of true
16:52:43 <dom> ... would this be all "true", or all to default value
16:53:35 <dom> ... re option 3, not clear how you stop forwarding
16:53:41 <dom> i/Youenn:/[slide 29]
16:53:44 <dom> ... I like option 4
16:53:54 <dom> Elad: I'm also liking it better now
16:54:27 <dom> Harald: defaults that push things in scope feel dangerous; option 1 is simple
16:54:47 <dom> ... having been to be explicit about the gestures you allow feel like an improvement
16:55:42 <dom> Elad: the dictionary would be needed now to help with future-proofing - developers can decide whether they want to be liberal or conservative with gesture forwarding
16:56:53 <dom> ... the app needs to decide which gestures to consume locally vs forward
16:57:15 <dom> Youenn: but part of I'm saying is that "wheel" vs "touch-scroll" is a useful distinction
16:58:02 <dom> Jan-Ivar: option 3 won't work given default true values
16:58:19 <dom> ... I like option 1 (?)
16:58:42 <dom> Guido: option 3, default values would have to be false
16:59:46 <dom> ... I think for safety reasons, option 1 & 3 are preferable
17:00:47 <dom> Elad: I suggested default to true for wheel given that's currently the only value, but I understand that's not right
17:03:21 <dom> Youenn: wheel is the wrong semantics - it should be about scrolling
17:03:55 <dom> harald: but a wheel event can be used for other things that scrolling
17:05:27 <dom> Guido: I don't like option 4 - I think we're unlikely to find consensus
17:07:00 <dom> Jan-Ivar: in the Chrome implementation, can the Web app intercept the event?
17:07:48 <dom> Elad: don't think so, would need to double check
17:08:48 <dom> Subtopic: Consideration of limitation to HTMLVideoElement
17:08:48 <dom> [slide 31]
17:10:41 <dom> [slide 32]
17:11:45 <dom> [slide 33]
17:16:02 <dom> Jan-Ivar: if you have an interactive overlay would already need to dispatch events
17:16:22 <dom> s/already/
17:16:45 <dom> ... to the video element
17:16:50 <dom> s/would/, it would
17:17:46 <dom> ... I didn't know that `pointer-events: none` prevented dispatching event handlers
17:19:50 <dom> ... Libraries would evolve to suppor this scenario
17:20:22 <dom> Elad: this isn't limited to trusted events; pointer-events make using event dispatch unworkable
17:21:40 <dom> [slide 34]
17:21:56 <dom> [slide 35]
17:26:07 <dom> Elad: heuristics can be applied independently of what element the API is applied to
17:26:48 <dom> Tim: hearing about these heuristics feels like it will be very problematic for developers to make sense of it
17:27:01 <dom> ... I don't think the target element changes this
17:27:12 <dom> ... but it feels like testing this will be hard
17:27:33 <dom> ... if somebody starts scribling over 2/3rd of the screen, will that stop working?
17:28:15 <dom> Jan-Ivar: it would be simpler to have it on the video element from an ergonomic perspective, and that pausing the video would stop the scrolling
17:28:32 <dom> ... in terms of UA mitigations, UA do clickjacking mitigations all the time
17:29:13 <dom> Guido: the UA is well positioned to know the binding between capture and the video element
17:29:37 <dom> ... restrictions are orthogonal to the element
17:34:21 <dom> Dom: I'm hearing that security restrictions are mostly orthogonal to that particular API surface,; I'm also hearing a bit of an ergonomic advantage to the video element (and I agree with it); but the issue with annotation and pointer-events is problematic
17:34:44 <dom> Jan-Ivar: I would like to have an opportunity to give a bette representation of my perspective
17:35:40 <dom> Elad: we're hearing developers request for this to work at least with canvas
17:35:57 <dom> Jan-Ivar: this could be something we extend to - it's the case for captureStream() for instance
17:38:55 <dom> Guido: supporting the core use case of annotation feels like something any proposal need to demonstrate
17:40:31 <dom> Jan-Ivar: I'll look into the pointer-events situation, that's new information to me
17:41:29 <dom> Youenn: is there a use case for an HTML element that isn't an overlay to a video element?
17:41:54 <dom> Elad: video *or* canvas which is an important part of the MVP for us
17:45:00 <dom> ... we're hearing requests (e.g. from Meet) to have this supported even if the video is only painted on a canvas
17:45:21 <dom> Dom: would be to hear more about the reasoning for these requests (to understand the trade off in adding that support)
17:45:31 <dom> Topic: Screen Capture
17:45:31 <dom> Subtopic: -> https://github.com/w3c/mediacapture-screen-share/issues/307 Suggest User Agents treat a captured tab as visible
17:45:31 <dom> [slide 37]
17:50:28 <dom> Harald: when you capture a browser *window* it includes the chrome of the browser
17:50:52 <dom> ... and a browser could capture the window of another browser
17:52:50 <dom> Youenn: the described behavior makes some sense to me; would this be guidance or required?
17:53:24 <dom> ... I would be fine with guidance, not sure about requiring it, esp for window
17:53:43 <dom> Jan-Ivar: I would be happy with SHOULD for both
17:54:04 <dom> ... we want to avoid having a browser page throttled when being captured
17:54:31 <dom> Youenn: SHOULD SGTM
17:54:45 <dom> Elad: is this tab-only or window too?
17:55:03 <dom> Jan-Ivar: both
17:55:12 <dom> Elad: tab would seem to be an easy starting point
17:55:48 <dom> Harald: I'm happy with a MUST for tabs, needs more time to discuss if this is feasible for window
17:56:23 <dom> ... maybe discuss this in a new issue
17:57:05 <dom> Dom: re window, are we only talking about browser window of the same UA? is that really harder than a tab?
17:57:24 <dom> Elad: a browser cannot necessarily detect that it is being window-captured depending on the OS
17:57:50 <dom> ... hence why I suggest starting with tabs
17:58:28 <dom> Youenn: if a window is fully occluded, an OS may not provide any frame (and thus throttling might actually be the right thing)
17:59:00 <dom> ... we can give advice in that direction, without having the spec trying to require it
17:59:10 <dom> Jan-Ivar: how about MUST for tab capture?
17:59:13 <dom> Youenn: SGTM
18:00:01 <dom> Tim: I don't see it needed for window - if it works only sometimes, that's harder to explain to users
18:00:10 <dom> ... let's do it just for tabs, as a MUST
18:00:31 <dom> Elad: are there other states that ought be treated the same way as visibility?
18:00:56 <dom> RESOLVED: focus on tab capture and make it a requirement (MUST)
18:01:17 <dom> Youenn: we should look into other properties
18:01:26 <dom> Elad: e.g. blur (that's the only one I can think of)
18:01:31 <dom> RRSAgent, draft minutes
18:01:32 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/21-webrtc-minutes.html dom
18:30:01 <Zakim> Zakim has left #webrtc