[Minutes] Editing WG - 2025-09-11

08:02 <whsieh> issue: https://github.com/w3c/editing/issues/487
08:02 <whsieh> feedback about beforeinput events, planned presentation at TPAC
08:02 <whsieh> johanneswilm: if you have any topics for TPAC, feel free to add
08:02 <whsieh> johanneswilm: next issue: https://github.com/w3c/editing/issues/488
08:03 <whsieh> johanneswilm: new document describing caret movement, etc. that isn't execCommand or contentEditable
08:03 <whsieh> johanneswilm: if you have a good naming suggestion, please add to 488
08:04 <whsieh> next issue: https://github.com/w3c/clipboard-apis/issues/240
08:04 *** edgar (~uid184785@efd23fc2.public.cloak) has joined the channel 
08:05 <whsieh> Ashish: we'd discussed last meeting, with proposal to specify optional list of types when reading
08:05 <whsieh> Ashish: annevk — WebKit already lazily reads the data
08:05 <whsieh> Ashish: these are two approaches to solving the lazy loading problem
08:06 <whsieh> Ashish: there is an advantage to having explicit types passed in though
08:06 <whsieh> Ashish: backwards compatibility
08:08 <whsieh> annevk: given Safari has already shipped this, having engines change implementation is nicer because websites can get better performance without adoption
08:08 <whsieh> annevk: otherwise, we can't expect web developers to get the performance benefit at scale
08:08 <dandclark> q+
08:09 <whsieh> annevk: bit of wiggle room because browsers already diverge a bit
08:09 <whsieh> dandclark: what is the Mozilla behavior?
08:09 <whsieh> dandclark: if Firefox does match Chrome, would you consider aligning with Safari?
08:10 <whsieh> edgar: currently, all the data is read up front
08:10 <whsieh> edgar: also happy to change if spec changes
08:11 <whsieh> dandclark: this is measurable, we could add telemetry to measure how often websites read, then clipboard changes, then website calls getType
08:11 <whsieh> dandclark: need to check with Chromium editor (?) to see if it's measurable
08:11 <whsieh> Ashish: not sure we can measure this, but we'll see
08:11 <whsieh> Rakesh: given the spec in its current state, how big of a risk would it be to change this behavior?
08:12 <whsieh> q+
08:12 <whsieh> Rakesh: would it be a big risk? how would backwards compatibility work?
08:14 <whsieh> annevk: in terms of risk, there would be less risk in the types array proposal but if we do it lazy by default, there would be more win
08:14 <whsieh> annevk: so there is a bit of a kind of "risk" both ways
08:16 <whsieh> annevk: we've made changes in the past where one browser deviates, but if it makes a lot more sense for that approach, we'll align to that approach
08:17 <whsieh> dandclark: safari behavior seems potentially surprising?
08:17 <whsieh> annevk: it's like the file object
08:17 <whsieh> annevk: items will only change once the new event we defined, clipboardChange, is fired
08:18 <johanneswilm> q+
08:19 <whsieh> johanneswilm: just thinking of where this might apply.... if there's a paste as plain text in collaborative editor and goes to the server, but server rejects the change, and then goes back to the user...
08:19 <whsieh> annevk: it would only fail if the user copied in between
08:21 <dandclark> q+
08:22 <whsieh> johanneswilm: (to clarify — with collaborative editors, changes may need time to be resolved with other users editing at the same time)
08:23 <whsieh> annevk: we currently throw, but open to changing that
08:23 <whsieh> dandclark: even in the non-collab editor, we now have the risk where `getType` might throw
08:24 <whsieh> zgroza: someone asked before if we're able to measure whether websites are able to depend on long-delayed read
08:24 <whsieh> zgroza: I think we could add those metrics once we have the clipboard change event
08:25 <whsieh> Rohan: re: backwards compatibility... could web apps that maintain history be using that clipboard item to represent undo/redo item?
08:26 <whsieh> Rohan: right now it's possible to store those apps in memory for a long time and getType later
08:27 <whsieh> Rohan: on *redo*, the app would read the data again
08:28 <whsieh> johanneswilm: could we add a note to indicate that they shouldn't try to store these clipboard items in editing history?
08:30 <whsieh> annevk: there are a number of ways getType can reject
08:31 <whsieh> annevk: we should probably return an empty blob for now instead of rejecting
08:31 <whsieh> annevk: (maybe a flag on the ClipboardItem to indicate if its invalid?)
08:31 <whsieh> dandclark: might be a bit of a race there
08:32 <whsieh> Rohan: could we instead cache after getType() the first time?
08:32 <whsieh> whsieh: seems like a good idea
08:33 <whsieh> whsieh: appears to fix all issues raised so far
08:34 <whsieh> johanneswilm: what are the cons of this approach
08:37 <whsieh> smaug: would be good to have telemetry
08:38 <dandclark> https://www.irccloud.com/pastebin/qdTHEUID/
08:38 <whsieh> > How *does* the permissions story work in Safari today? My understanding is that the permission is only gated at the `clipboard. read()` call. But if I only need to get permission at `clipboard.read`, and then ClipboardItem will always give me a live view of the clipboard with `getType()`, can I basically snoop on the clipboard forever by holding onto the `ClipboardItem`?
08:38 <whsieh> On the other hand, pushing the permissions check out to `ClipboardItem.getType()` seems unfortunate, because we have to redo the permissions check for every type that we want to read.
08:39 <whsieh> annevk: item gets invalidated so you only get to access then and there
08:39 <whsieh> annevk: at some point getType starts failing if there's a new item
08:40 <whsieh> dandclark: if you vend out a clipboard item, you track whether the clipboard has changed
08:41 <whsieh> Rohan: what happens to the types of the clipboard item over time?
08:41 <whsieh> annevk: I think a snapshot makes the most sense
08:41 <whsieh> annevk: maybe separately we want to expose whether it got invalidated
08:42 <whsieh> Rohan: maybe the types attributes should also be fetched live to align with getTyope
08:43 <whsieh> smaug: seems racy
08:43 <whsieh> annevk: maybe there should be a separate async thing to check if the item is invalid?
08:44 <whsieh> smaug: that still seems racy
08:45 <whsieh> Rakesh: if we take discussion back to the original issue… does the original proposal satisfy all constraints
08:45 <whsieh> annevk: no (see ealrier)
08:46 <whsieh> Ashish: is it fine if we first get the telemetry data, and check how often the clipboard changes between getType?
08:47 <whsieh> smaug: yeah, that makes sense. and also, measure how often getType is called more than once
08:47 <smaug> https://w3c.github.io/clipboard-apis/#issue-0a41fcd5
08:47 <whsieh> johanneswilm: no matter which approach is chosen, maybe we should add the note into the spec that authors shouldn't store and read the clipboardItem for persistent state?
08:51 <whsieh> issue: https://github.com/w3c/clipboard-apis/pull/239
08:53 <whsieh> zgroza: agree that websites probably would never be able to observe this difference, but seems like a more intuitive model in regards to what the user would expect, w.r.t. partitions
08:53 <whsieh> annevk: on the same page