minutes call 2023-11-09

scribe: whsieh [17:03] <sanketj_> present+ [17:03] <dandclark> present+
[17:04] <smaug> present+ [17:05] <whsieh> johanneswilm: issue 198 in
clipboard apis [17:05] <comandeer> present+ [17:05] <whsieh> johanneswilm:
skip to input events [17:05] <whsieh> johanneswilm:
https://github.com/w3c/input-events/issues/147 [17:05] <whsieh>
johanneswilm: allowed in FF and Chrome, but not WebKit (at the moment)
[17:06] <whsieh> q+ [17:07] <whsieh> yep. we should add those arguments to
the event init [17:08] --> snianu (~snianu@7e4e2622.public.cloak) has
joined this channel. [17:09] <snianu> present+ [17:09] <whsieh> smaug:
weird that getter is inconsistent with init arguments [17:09] <whsieh>
johanneswilm: next issue: https://github.com/w3c/input-events/issues/146
[17:10] <dandclark> q+ [17:10] --> edgar (~uid184785@7e4e2622.public.cloak)
has joined this channel. [17:11] <whsieh> johanneswilm: should we align
getTargetRanges in all cases? or just some types of ranges? [17:12]
<whsieh> dandclark: w.r.t. EditContext, getTargetRanges is needed for many
commands [17:12] <whsieh> dandclark: for deletion cmds we have them zeroed
out [17:12] <whsieh> (does "zeroed out" mean empty range? or null range?)
[17:12] <whsieh> I see, thanks [17:13] <whsieh> dandclark: this makes it so
that sites are unlikely to rely on this, while we figure this out [17:13]
<whsieh> johanneswilm: would be best to not have them removed [17:14]
<whsieh> dandclark: if we ship with them working differently, compat will
be difficult moving forward [17:15] <whsieh> johanneswilm: the non-trivial
deletion commands need getTargetRanges (request from JS authors) [17:15]
<whsieh> johanneswilm: ...such as delete word, delete sentence, etc.
[17:15] <whsieh> johanneswilm: FB's editor just uses API for extending
selection to determine ranges [17:15] <whsieh> johanneswilm: masayuki felt
that was not a good way [17:16] <whsieh> johanneswilm: unrealistic to align
on complex editing like table merging, paragraph merging [17:16] <whsieh>
johanneswilm: maybe we can align on behaviors when selection is collapsed
[17:16] <whsieh> johanneswilm: (and align on accented character behavior)
[17:17] <whsieh> johanneswilm: on several platforms it's common to delete
the accent first and then delete the base char [17:17] <whsieh> q+ [17:17]
<whsieh> johanneswilm: I'm a bit afraid that we may never get full
agreement [17:19] <whsieh> whsieh: can we use insert text replacement?
[17:20] <whsieh> example character: b̂ [17:20] <whsieh> johanneswilm:
Chrome only deletes accent mark, target range is inconsistent [17:21]
<whsieh> johanneswilm: or actually it makes sense because target character
is affected? [17:21] <whsieh> q+ [17:22] <whsieh> johanneswilm: defn. of
target ranges is very wishy-washy [17:22] <whsieh> johanneswilm: however,
for these character type of deletions it makes sense to be more specific
[17:23] <whsieh> johanneswilm: we should specify this character deletion
case, maybe not in the table/paragraph merge case [17:24] <whsieh>
dandclark: approach sounds good to me [17:25] <whsieh> smaug: doesn't cover
the extent of #146 [17:25] <whsieh> johanneswilm: resolution is: be more
specific in char-level deletions [17:25] <whsieh> next up:
https://github.com/w3c/clipboard-apis/pull/198 [17:26] <snianu> trying to
speak [17:26] <snianu> can you hear me? [17:26] <whsieh> snianu: audio
issues, let's move on for now [17:26] <whsieh> snianu: nvm audio issues
fixed! [17:27] <whsieh> snianu: if clipboard item is empty and developer
writes to clipboard, the write will throw an exception in Chrome but
FF/WebKit allows that [17:28] <whsieh> s/clipboard item is empty/clipboard
item list is empty/ [17:28] <whsieh> snianu: creates confusion for web dev
since it's unclear if they need to retry, or… [17:28] <whsieh> q+ [17:29]
<dandclark> q+ [17:29] <whsieh> s/developer writes to clipboard/developer
reads from clipboard/ [17:29] <whsieh> q- [17:29] <whsieh> snianu: read
should not throw exception, write should throw exception [17:30] <whsieh>
snianu: with current DT APIs dev cannot clear clipboard by writing [17:30]
<whsieh> snianu: with async clipboard API you can write empty item (?)
[17:30] <whsieh> snianu: maybe flag to indicate that clipboard item is
intentionally "empty" [17:30] <whsieh> q+ [17:32] <whsieh> whsieh: if we
want to expose a "clear clipboard" API, it should probably be
navigator.clipboard.clear() or something [17:33] <whsieh> johanneswilm:
seems we're all in agreement [17:33] <whsieh> sanketj_: to summarize, allow
read empty items [17:34] <whsieh> can you link it? [17:34] <whsieh> next
up: https://github.com/w3c/editing/issues/439 [17:35] <whsieh> snianu:
WebKit says "web custom formats are a tracking vector" [17:35] <whsieh>
snianu: discussed this with internal privacy folks [17:36] <whsieh> snianu:
can we allow max 5 custom formats? [17:36] <whsieh> johanneswilm: is this
up to UA, or baked into spec [17:37] <whsieh> snianu: current proposal is
to add to spec [17:38] <whsieh> smaug: unclear if this addresses anything
since you could have app that only reads 1 type of data [17:39] <whsieh>
smaug: doesn't mitigate core issue [17:40] <whsieh> snianu: if you only
have < 5 types, tracking vector is smaller [17:40] <whsieh> q+ [17:40]
<whsieh> snianu: making it harder for sites to detect [17:41]
<johanneswilm> q+ [17:41] <whsieh> whsieh: not robust to collusion [17:42]
<whsieh> snianu: 5 is just an arbitrary number. maybe we can start with 1?
[17:42] <sanketj_> q+ [17:43] <whsieh> snianu: ack that sites can use the
same 5 custom formats to track users across web [17:43] <whsieh> snianu: it
does restrict to small number at least [17:44] <whsieh> johanneswilm: if
you had 1000 custom formats, you could have an app that spams arbitrary
types on the clipboard, can't do this kind of spam with only limited number
of types [17:48] --> whsieh_ (~whsieh@7e4e2622.public.cloak) has joined
this channel. [17:48] <johanneswilm> q+ [17:49] <whsieh_> sanketj_: the
first time you paste it'll get populated on the clipboard [17:50] <whsieh_>
whsieh: collusion is a problem with custom formats in general, not just the
limit [17:51] <-- whsieh (~whsieh@7e4e2622.public.cloak) has left this
server (Ping timeout: 180 seconds). [17:52] <whsieh_> sanketj_: best thing
we can do while still enabling this use case is limit privacy impact
[17:52] <whsieh_> sanketj_: don't allow too many custom formats to be
delayed [17:53] <whsieh_> sanketj_: privacy problems are inherent to API
[17:53] <whsieh_> sanketj_: source app is going to know that custom format
was pasted in [17:53] <whsieh_> *destination*? [17:53] <whsieh_>
johanneswilm: we should continue discussion in the issue [17:53] <whsieh_>
I can ping Anne and discuss offline [17:54] <whsieh_> johanneswilm: maybe
another dedicated meeting slot [17:55] <whsieh_> johanneswilm: let's move
on — https://github.com/w3c/edit-context/issues/71 [17:55] <whsieh_>
johanneswilm: what connection should there be between execCommand and EC?
[17:55] <dandclark> q+ [17:56] <whsieh_> dandclark: agree with
johanneswilm, copy needed. agree with masayuki, we don't generally want to
support this [17:57] <edgar> q+ [17:57] <whsieh_> dandclark: simplest
solution: commands that are available when focused in non-EC should be
available in EC [17:58] <whsieh_> edgar: we are working on shipping
clipboard API (?) [17:58] <whsieh_> johanneswilm: resolve on dandclark's
comment above [17:58] <sanketj_> s/privacy problems are inherent to
API/source app will have to know when a paste happens and what format is
requested/ [17:58] <whsieh_> https://github.com/w3c/edit-context/issues/74
[17:59] <whsieh_> dandclark: cE=false with nested cE=true works [17:59]
<whsieh_> dandclark: EC should work the same way, make it possible to nest
[17:59] <whsieh_> dandclark: is in line with previous resolution [18:00]
<whsieh_> dandclark: if no CE=false, then EC is ignored johanneswilm:
resolve on dandclark's comment above

-- 
Johannes Wilm, PhD
tel +46766922220
https://www.johanneswilm.org