[minutes] January 2025 meeting

Hi,

The minutes of our meeting held yesterday (Jan 21st) are available at
   https://www.w3.org/2025/01/21-webrtc-minutes.html

and copied as text below.

Dom

                       WebRTC January 2025 meeting

21 January 2025

    [2]Agenda. [3]IRC log.

       [2] https://www.w3.org/2011/04/webrtc/wiki/November_19_2024
       [3] https://www.w3.org/2025/01/21-webrtc-irc

Attendees

    Present
           BernardA, Carine, Cullen, Dom, Elad, FrederikSolengerg,
           Guido, Harald, Jan-Ivar, JasperHugo, PatrickRockhill,
           PeterT, SunShin, TimP, Tove, Youenn

    Regrets
           -

    Chair
           Bernard, Guido, Jan-Ivar

    Scribe
           dom

Contents

     1. [4]Captured Surface Control
          1. [5]Zoom control
          2. [6]oncapturedzoomlevelchange
          3. [7]get/setSupportedZoomLevels()
          4. [8]Scroll control
          5. [9]Forwarding other gestures
          6. [10]Consideration of limitation to HTMLVideoElement
     2. [11]Screen Capture
          1. [12]Suggest User Agents treat a captured tab as
             visible
     3. [13]Summary of resolutions

Meeting minutes

    Slideset: [14]https://docs.google.com/presentation/d/
    1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/ ([15]archived PDF
    copy)

      [14] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/

   [16]Captured Surface Control

      [16] https://github.com/w3c/mediacapture-surface-control/

     [17]Zoom control

      [17] https://github.com/w3c/mediacapture-surface-control/issues/27

    [18][Slide 10]

      [18] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#10

    [19][Slide 11]

      [19] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#11

    Elad: implemented in Chrome like css zoom

    [20][Slide 12]

      [20] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#12

    [21][Slide 16]

      [21] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#16

    [22][Slide 13]

      [22] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#13

    [23][Slide 14]

      [23] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#14

    Jan-Ivar: supports the attribute
    … there is a separate discussion about where the API should
    belong
    … instead of nullable, you suggest a default to 100?

    Elad: re API anchoring, that discussion was around gestures,
    not for zoom level?

    Jan-ivar: let's discuss the anchoring question later
    … although it would have been good to discuss this topic first

    Cullen: could you tell more about how safe is this approach?
    given risks of overexposure

    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?

    Cullen: is the latter implicit or explicit?

    Elad: this is in origin trial if you want to try - it comes
    with an explicit chrome level prompt

    Cullen: I'll give it a try - it feels risky

    youenn: attribute is an improvement; nullability allows to
    express whether zoomability has a meaning for the given surface
    … re API anchoring, we should discuss this; we had discussed in
    the past multiple surfaces captured in a single getDisplayMedia
    … we need to future-proof the API since that's one use case we
    know about

    RESOLUTION: zoomLevel is an attribute, nullable for now but may
    be revisited

    Jan-Ivar: note that developers will need to test for undefined
    already since it's only available in one browser atm

    HTA: there is a complexity cost to future proofing - I prefer
    designing for current requirement set

     oncapturedzoomlevelchange

    [24][Slide 15]

      [24] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#15

    [25][Slide 16]

      [25] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#16

    Youenn: feels like the event name is too long - we can bikeshed
    it later

     [26]get/setSupportedZoomLevels()

      [26] https://github.com/w3c/mediacapture-surface-control/issues/40

    [27][Slide 17]

      [27] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#17

    [28][Slide 18]

      [28] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#18

    [29][Slide 19]

      [29] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#19

    [30][Slide 20]

      [30] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#20

    [31][Slide 21]

      [31] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#21

    Jan-Ivar: using Youenn's proposal allows to remove
    getZoomLevels(), which has risks of creating interop issues
    … also has nicer safety characteristics to avoid a malicious
    app to over-zoom

    Youenn: +1 to the increase/decrease API; could you say more
    about the need resetZoomLevel()?

    Elad: re removing the need of getZoomLevels, you still need it
    to know whether you've hit a max
    … we've heard the need for reset from product teams

    Youenn: at least getSupportedZoomLevels() would only to report
    the extremes

    Harald: setZoomLevel feels more ergonomic

    Dom: you could return false to indicate that you've reached an
    extreme value

    Elad: but that doesn't work when starting from the extreme

    Elad: I'm hearing support to move forward with
    increase/decrease/reset, and simplify getSupportedZoomLevels()
    to a range

    RESOLUTION: Use increase/decrease/resetZoomLevel() and simplify
    getSupportedZoomLevels() to a range

     Scroll control

    [32][Slide 23]

      [32] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#23

    [33][Slide 24]

      [33] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#24

    Youenn: the costs for spec authors and implementers seem low

    Elad: the implementation cost is not negligible

    Dom: you could imagine applying effects on a local capture to
    e.g. visualize different color scheme on a design

    Jan-Ivar: from a logical perspective, this is a one-to-many
    relationship

     [34]Forwarding other gestures

      [34] https://github.com/w3c/mediacapture-surface-control/issues/47

    [35][Slide 25]

      [35] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#25

    Jan-Ivar: touch events would probably be applicable to e.g.
    windows tablets
    … for scrolling

    [36][Slide 26]

      [36] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#26

    [37][Slide 27]

      [37] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#27

    [38][Slide 28]

      [38] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#28

    [39][Slide 29]

      [39] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#29

    Youenn: forwardGestures(el, false) is pretty clear - not sure
    about the meaning of true
    … would this be all "true", or all to default value
    … re option 3, not clear how you stop forwarding
    … I like option 4

    Elad: I'm also liking it better now

    Harald: defaults that push things in scope feel dangerous;
    option 1 is simple
    … having been to be explicit about the gestures you allow feel
    like an improvement

    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
    … the app needs to decide which gestures to consume locally vs
    forward

    Youenn: but part of I'm saying is that "wheel" vs
    "touch-scroll" is a useful distinction

    Jan-Ivar: option 3 won't work given default true values
    … I like option 1 (?)

    Guido: option 3, default values would have to be false
    … I think for safety reasons, option 1 & 3 are preferable

    Elad: I suggested default to true for wheel given that's
    currently the only value, but I understand that's not right

    Youenn: wheel is the wrong semantics - it should be about
    scrolling

    harald: but a wheel event can be used for other things that
    scrolling

    Guido: I don't like option 4 - I think we're unlikely to find
    consensus

    Jan-Ivar: in the Chrome implementation, can the Web app
    intercept the event?

    Elad: don't think so, would need to double check

     [40]Consideration of limitation to HTMLVideoElement

      [40] https://github.com/w3c/mediacapture-surface-control/issues/45

    [41][Slide 31]

      [41] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#31

    [42][Slide 32]

      [42] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#32

    [43][Slide 33]

      [43] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#33

    Jan-Ivar: if you have an interactive overlay , it would need to
    dispatch events
    … to the video element
    … I didn't know that `pointer-events: none` prevented
    dispatching event handlers
    … Libraries would evolve to suppor this scenario

    Elad: this isn't limited to trusted events; pointer-events make
    using event dispatch unworkable

    [44][Slide 34]

      [44] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#34

    [45][Slide 35]

      [45] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#35

    Elad: heuristics can be applied independently of what element
    the API is applied to

    Tim: hearing about these heuristics feels like it will be very
    problematic for developers to make sense of it
    … I don't think the target element changes this
    … but it feels like testing this will be hard
    … if somebody starts scribling over 2/3rd of the screen, will
    that stop working?

    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
    … in terms of UA mitigations, UA do clickjacking mitigations
    all the time

    Guido: the UA is well positioned to know the binding between
    capture and the video element
    … restrictions are orthogonal to the element

    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

    Jan-Ivar: I would like to have an opportunity to give a bette
    representation of my perspective

    Elad: we're hearing developers request for this to work at
    least with canvas

    Jan-Ivar: this could be something we extend to - it's the case
    for captureStream() for instance

    Guido: supporting the core use case of annotation feels like
    something any proposal need to demonstrate

    Jan-Ivar: I'll look into the pointer-events situation, that's
    new information to me

    Youenn: is there a use case for an HTML element that isn't an
    overlay to a video element?

    Elad: video *or* canvas which is an important part of the MVP
    for us
    … we're hearing requests (e.g. from Meet) to have this
    supported even if the video is only painted on a canvas

    Dom: would be to hear more about the reasoning for these
    requests (to understand the trade off in adding that support)

   Screen Capture

     [46]Suggest User Agents treat a captured tab as visible

      [46] https://github.com/w3c/mediacapture-screen-share/issues/307

    [47][Slide 37]

      [47] 
https://docs.google.com/presentation/d/1XbWX8qrgaXQIQ2zQoh1RW4dUDbztaM7uCW9ZFnDvpWk/#37

    Harald: when you capture a browser *window* it includes the
    chrome of the browser
    … and a browser could capture the window of another browser

    Youenn: the described behavior makes some sense to me; would
    this be guidance or required?
    … I would be fine with guidance, not sure about requiring it,
    esp for window

    Jan-Ivar: I would be happy with SHOULD for both
    … we want to avoid having a browser page throttled when being
    captured

    Youenn: SHOULD SGTM

    Elad: is this tab-only or window too?

    Jan-Ivar: both

    Elad: tab would seem to be an easy starting point

    Harald: I'm happy with a MUST for tabs, needs more time to
    discuss if this is feasible for window
    … maybe discuss this in a new issue

    Dom: re window, are we only talking about browser window of the
    same UA? is that really harder than a tab?

    Elad: a browser cannot necessarily detect that it is being
    window-captured depending on the OS
    … hence why I suggest starting with tabs

    Youenn: if a window is fully occluded, an OS may not provide
    any frame (and thus throttling might actually be the right
    thing)
    … we can give advice in that direction, without having the spec
    trying to require it

    Jan-Ivar: how about MUST for tab capture?

    Youenn: SGTM

    Tim: I don't see it needed for window - if it works only
    sometimes, that's harder to explain to users
    … let's do it just for tabs, as a MUST

    Elad: are there other states that ought be treated the same way
    as visibility?

    RESOLUTION: focus on tab capture and make it a requirement
    (MUST)

    Youenn: we should look into other properties

    Elad: e.g. blur (that's the only one I can think of)

Summary of resolutions

     1. [48]zoomLevel is an attribute, nullable for now but may be
        revisited
     2. [49]Use increase/decrease/resetZoomLevel() and simplify
        getSupportedZoomLevels() to a range
     3. [50]focus on tab capture and make it a requirement (MUST)

Received on Wednesday, 22 January 2025 12:49:39 UTC