[Minutes] Editing WG - 2025-03-13

08:01 <whsieh> https://github.com/w3c/clipboard-apis/issues/227
08:02 <whsieh> Rohan: main concern was interop
08:02 <whsieh> Rohan: not supported by Safari/FF — based on permissions API model
08:03 <whsieh> Rohan: major changes: (1) removed permissions req, (2) clipboard change event only fires if the document is in focus (i.e. tab is active?)
08:04 <whsieh> and we don't provide clipboard data as part of the event
08:04 <whsieh> we do provide type info, but *only* native types
08:04 <whsieh> Rohan: we'd like to know if there are any further concerns
08:05 <whsieh> Rohan: even if the clipboard changes multiple times, events are batched
08:05 <whsieh> (upon returning to the tab)
08:05 <whsieh> annevk: is this an alternative to polling?
08:06 <whsieh> Rohan: yeah, that scenario should be handled by this event-based solution 
08:07 <whsieh> annevk: this seems to expose more than just the "changed" bit. would expose types
08:07 <whsieh> Rohan: but only native types. not custom types, which reduces FP surface
08:08 <whsieh> Rohan: a RTE that supports pasting multiple rich types may want to know types in order to know what UI to enable based on the contents of the clipboard (e.g. different paste buttons)
08:09 <whsieh> annevk: seems like a questionable user experience
08:10 <whsieh> jyasskin: the explainer contains screenshots of the actual UI in practice e
08:10 <whsieh> jyasskin: these are existing use cases
08:14 <whsieh> annevk/whsieh: is "tab active" enough of a bar?
08:14 <whsieh> jyasskin: that seems fair, but think about what you do in a spreadsheet app before you paste
08:14 <whsieh> jyasskin: you may not have pasted anything else..
08:15 <whsieh> smaug: maybe raise the bar to sticky activation?
08:15 <whsieh> annevk: want to hear from the proposer of the other API (polling-based?)
08:15 <whsieh> zgroza: seems like this event-based API would cover most of the use cases
08:16 <whsieh> zgroza: there are some other use cases that may require contentsID + clipboard change event
08:16 <whsieh> zgroza: from discussing with devs who want to use it, doesn't seem like they are necessary for critical use cases
08:16 <whsieh> annevk: can you elaborate on the edge cases that aren't addressed?
08:17 <whsieh> zgroza: when you use web custom formats, you need to read the clipboard in order to see if it has changed..
08:17 <whsieh> zgroza: you may be triggering delayed rendering mechanisms in the system
08:17 *** jyasskin (~sid50823@ecc4d82f.public.cloak) has joined the channel 
08:18 <whsieh> zgroza: if you have many windows in your app, each one of them will receive an event
08:18 <whsieh> zgroza: then again, those use cases can be solved with some better heuristics
08:18 <whsieh> zgroza: the extra overhead of reading clipboard data is likely not so big
08:19 <whsieh> zgroza: we'll see how that works with clipboard change event
08:19 <whsieh> zgroza: we'll revisit if there's a compelling use case not covered by event
08:19 <whsieh> smaug: have q about 5.4: does that mean that even if unsupported clipboard types change, we still fire an event?
08:20 <whsieh> smaug: currently there would be a clipboard event change even if no supported types change
08:20 <whsieh> Rohan: my guess is that whenever you write to the clipboard, it would trigger an event. not just telling that the types have changed, but also the clipboard data
08:21 <whsieh> Rohan: allows sites with permission in Chrome to read data
08:21 <whsieh> jyasskin: I think the primary use case for firing change events that don't have types that the site can use is the one that Chromium cares about: remote desktops
08:22 <whsieh> jyasskin: in order for Remote Desktop use case to work without arbitrary clipboard access, TAG suggested that the web app should show a button to trigger paste
08:23 <whsieh> johanneswilm: what are the next steps?
08:23 <whsieh> Rohan: we'd like to prototype in Chromium
08:23 <whsieh> Rohan: ...and see how it's received by devs
08:23 <whsieh> smaug: I hope the explainer will be updated to include sticky activation
08:23 <whsieh> johanneswilm: spec-wise, does anything need to happen?
08:24 <whsieh> Rakesh: let's get spec draft started
08:24 <whsieh> smaug: having a spec PR to review would be good
08:24 <whsieh> johanneswilm: makes sense. but no showstoppers?
08:25 <whsieh> smaug: this looks like a reasonable proposal so far
08:25 <whsieh> dandclark: something that may be helpful — official positions from WK and Gecko
08:26 <whsieh> let's skip https://github.com/w3c/clipboard-apis/issues/232, dupe of above
08:26 <whsieh> next: https://github.com/w3c/edit-context/issues/111
08:27 <whsieh> dandclark: the main issue is shipping due to compat concerns
08:27 <whsieh> dandclark: I talked with gdocs eng, they have some concerns
08:27 <whsieh> dandclark: few ways forward: build way to opt in to behavior change
08:27 <whsieh> dandclark: (not desirable, would be good for new behavior to be the default)
08:28 <whsieh> dandclark: another alternative: origin trials? CodeMirror, GDocs can try it out
08:28 <whsieh> dandclark: next steps — implement in Chromium behind flkag
08:28 <whsieh> *flag*
08:28 <whsieh> dandclark: from this group, we already have agreement to move forward with it
08:28 <whsieh> dandclark: no other changes from what we previously discussed
08:29 <whsieh> johanneswilm: how long would it take to go ahead with one of the above?
08:30 <whsieh> dandclark: in terms of shipping something to the public, I think we'll have an update on what the rollout plan is by the next monthly WG meeting
08:30 <whsieh> dandclark: maybe couple months if we were to ship behind flag
08:30 <whsieh> feasible that we would start rolling out on experimental basis on next few months
08:31 <whsieh> dandclark: we'd recommend other browsers just start by implementing the new behavior
08:31 <whsieh> (we all agree it's better)
08:32 <whsieh> dandclark: worst case scenario is that old *needs* to be the default due to compat
08:32 <whsieh> ...with Chrome
08:33 <whsieh> https://github.com/w3c/input-events/issues/162?
08:34 <whsieh> johanneswilm: last time: we decided we need tests
08:34 <whsieh> johanneswilm: masayuki wrote some tests can be adjusted to cover these scenarios too
08:35 <whsieh> smaug: curious about following the Chromium bug...
08:36 <whsieh> dandclark: we were waiting for tests to make a change
08:36 <whsieh> dandclark: (so we know the full story)
08:37 <whsieh> johanneswilm: there was a long discussion about the selection API…
08:37 <whsieh> johanneswilm: was resolved just a few days ago
08:37 <whsieh> johanneswilm (PR #345 in the selection API)