17:02:06 RRSAgent has joined #editing 17:02:06 logging to https://www.w3.org/2021/11/12-editing-irc 17:02:15 present+ 17:02:16 RRSAgent, make the logs public 17:02:16 I'm logging. I don't understand 'make the logs public', Travis. Try /msg RRSAgent help 17:02:17 AlexK has joined #editing 17:02:27 RRSAgent, make the minutes public 17:02:27 I'm logging. I don't understand 'make the minutes public', Travis. Try /msg RRSAgent help 17:02:42 present+ 17:02:46 According to https://github.com/w3c/editing/ 17:04:34 scribe: Travis 17:04:50 meeting: November 12, 2021 Web Editing WG Meeting 17:05:41 topic: Encourage browser to include files in beforeinput DataTransfer event (#120) 17:06:06 johanneswilm: had a followup with @wereHamster to check if the behavior worked according to how the filer noted. 17:06:11 .. so, yes it did. 17:06:24 BoCupp: Request was to add support (like Safari) 17:07:08 .. but like I said last time, wasn't a fan of having redundant info in beforeinput when we already have cut/copy events and async clipboard. 17:07:19 .. so isn't clear why we need them... but we have them! 17:07:24 .. request is for Safari to add them. 17:07:36 .. I'm OK either way: remove them, or everyone adds them. 17:07:48 github: https://github.com/w3c/input-events/issues/120 17:08:00 johanneswilm: what was Safari's position? 17:08:06 whsieh: we would not be opposed. 17:08:21 .. can see the value if they were already using beforeinput... but there are more forward thinking alternatives. 17:08:35 Travis: is there an action item? 17:08:54 BoCupp: we could document that it's different in different browsers.. but would love to settle on one? 17:09:00 .. whsieh want to pick? 17:09:08 .. j/k 17:09:23 whsieh: no reason why we ommitted it (except it wasn't originally in the spec). 17:09:27 .. seems sensible to add. 17:09:46 .. two parts to this.. 1) .files and... 17:10:00 .. oh, another thing: the .items function here... 17:10:10 .. wondering if it should also be in datatransferlist 17:10:36 text/uri-list 17:10:36 .. and 2) textURI-list 17:10:59 BoCupp: For #2 above, is it clear we should copy that? 17:11:21 whsieh: hmm... it should be consistent with copy/paste APIs... may be platform dependent. 17:11:45 .. in Safari, copy/paste the URL in the browser, you get a URL on the pasteboard.. 17:12:02 BoCupp: Is there clear guideance for the Mac on how to put it there? 17:12:20 whsieh: the text/uri-list is really a hint for expecting... 17:12:41 .. high-order bit--datatransfer should align with copy/paste events. 17:13:08 BoCupp: right. You want the same information as in the preceding or following cut/copy/paste event 17:14:36 action: we want the contents of datatransfer property on the input/beforeinput event to match the associated property of the copy/paste event (clipboard event). 17:15:09 action: johanneswilm to update the spec text to ensure datatransfer property on the input/beforeinput event to match the associated property of the copy/paste event (clipboard event) 17:15:55 topic: pull requests on input-events (they are basically the same thing) 17:16:13 github: https://github.com/w3c/input-events/pull/122 17:16:25 johanneswilm: want to know if we have more information here... 17:16:44 .. looking to see if we can mark these as not required in the spec? 17:17:05 whsieh: to be clear, both alternatives are OK: remove them, or mark them as deprecated in the spec. 17:17:23 .. may be a precident for similar things marked deprecated but supported by webkit? extendSelection? 17:17:35 johanneswilm: what is desired? 17:18:02 BoCupp: If whsieh is fine with removing it (from both spec/webkit), that would be my preference. 17:19:17 action: land this pull request (that removes these events from the spec); expectation that they may get removed from webkit in the future. 17:20:37 topic: BoCupp: just saying... following the same events now opens the possibility of being able to fire them in the same order (across implementations) as well as frequency :) Topic for a future meeting. 17:21:19 topic: Make async clipboard APIs (read/write) to sanitize interoperably 17:21:36 github: https://github.com/w3c/clipboard-apis/issues/150 17:22:26 BoCupp: pull request open in chromium to write unsanitized to the clipboard (for well-known HTML format) AND reading with well-known format if unsanitized flag provided. 17:22:30 q+ 17:22:42 .. specific action for 150? 17:24:15 anupam: we decided that reading unsanitized HTML, web authors can opt-in to unsanitized text/html using new option (that takes a list of mime-types to read unsanitized). 17:24:29 BoCupp: That's the current plan for chromium 17:25:01 .. from @rniwa last comment is that this isn't something we want standardized. 17:25:03 ack whsieh 17:25:31 whsieh: when we last discussed, @annevk noted an API that blink would implement, but webkit would implement (but perhaps as a no-op). 17:25:55 .. we wanted unsanitized flag for compat with those who already adopted the read API. 17:26:02 .. how widespread is the adoption? 17:26:12 .. seems more sensible to move forward without sanitization for Blink? 17:26:18 .. just have the clients use the unsanitzed data? 17:26:32 anupam: I check the usage, it's 0.001 / 0.002 17:27:07 BoCupp: read is giving an "insert-ready" content... if these sites were relying on the browser to sanitize, could create a XSS vuln that we are creating... 17:27:22 whsieh: potential for XSS is present anyway (where there is no sanitization) 17:27:54 BoCupp: but we're changing the contract; there's an expectation that they have to write a sanitizer.. when they switch to read, they may have been glad that sanitizer is provided by the browser. 17:28:25 .. but if update the contract--nothing will signal to these people that they need to change to start sanitizing. 17:28:40 .. agree with whsieh points... but tough to change from sanitized->unsanitized. 17:28:50 whsieh: so does this need to be put into the spec? 17:29:00 .. seems more of a problem just for an implementation (blink) 17:29:18 .. maybe something that's not in the spec could be put in place for this case? 17:29:28 BoCupp: does webkit ever return unsanitized? 17:29:38 whsieh: copy/paste between same origin does this. 17:29:51 BoCupp: Oh, I thought you always produced a sanitized read? 17:30:14 whsieh: yes, that's for getData... we have a bug to do this for clipboard... 17:30:36 BoCupp: so you might have the same concern for that when you make that future change? 17:31:07 whsieh: in async clipboard, they always get sanitized. 17:31:18 .. don't expect there to be huge problems with getting unsanitized data. 17:31:41 BoCupp: we have a security review issue open; chromium security folks were saying we needed to be explicit. I think for read? or was it write? 17:31:51 .. in any case, need to cross-review with security folks. 17:31:55 q+ 17:32:04 .. suspect perhaps might not fly 17:32:16 whsieh: fwiw, that's webkit's stance. 17:32:29 .. maybe just not something that's in the spec. 17:32:59 BoCupp: there's a usefulness to this also--having the browser produce an "insert ready" fragment (like the default action for paste) 17:33:23 .. there's no primitive that exposes the browser's default processing. 17:33:49 .. Can get the clipboard data from a read today without needing complicated workarounds. 17:33:58 ack johanneswilm 17:34:28 johanneswilm: if usage is low, and text editing is happening in only a handful of libraries--could we check with them on if that's the major usage? 17:34:58 q+ 17:35:16 .. the "they have to just put it in the DOM without thinking" is dangerous--leads to them allowing everything to go through--but tables could break editor scenarios... JS sanitiation is usually needed anyway. 17:35:39 ack BoCupp 17:35:54 snianu has joined #editing 17:35:58 BoCupp: The default browser behavior for paste is to just insert it into contenteditable 17:36:20 .. agree with johanneswilm that the editor must be written to have a filter (for what can be edited) 17:36:31 .. however, it's the current default behavior for paste! 17:36:54 .. often we're exposing the internal of the browser... this is one more of those things. 17:37:30 .. there is a sanitizer that we employ but we're not giving access to it. Maybe through a sanitizer API with configuration that allows it to work like the paste to contenteditable? (Could be interesting.) 17:37:56 ... but we do something today that authors can't get today; additionally we have a web compat concern. So why not leave it? 17:40:02 Base: https://github.com/w3c/clipboard-apis/pull/158 17:40:20 Pickling: https://github.com/w3c/clipboard-apis/pull/162 17:40:40 action: wait for snianu's PRs (base: https://github.com/w3c/clipboard-apis/pull/158 pickling: https://github.com/w3c/clipboard-apis/pull/162). (It re-writes the spec with better algorithmic language. Then there's some pickling work on top of that... Would like folks in the WG to read/review the upcoming PRs. 17:41:13 topic: What happens if promises to Blobs are not resolved within a reasonable amount of time? (#161) 17:41:45 BoCupp: snianu added promises to dom strings or blobs so that clipboard could take a promise to its data in a write. 17:42:03 .. we were hearing feedback about the open-ended-ness of the promise? How long do we wait? 17:42:18 .. 2 seconds? a minute? indefinitely? 17:42:39 .. other issues: what if a second write happens? Is the first canceled? What about a write in another tab (across origin)? 17:42:50 .. is it what's in the foreground that takes precedence? 17:42:59 .. is it a matter of luck? 17:43:05 .. lots of corner cases! 17:43:17 whsieh: this is shipping. 17:43:24 .. out behavior is: no hard-coded timeout... 17:43:38 .. but if you leave the tab, the promise (prior call) is rejected. 17:43:57 BoCupp: If the tab leaves the foreground, or a second write occurs in the same time, this rejects the previous write promise. 17:44:01 whsieh: yes. 17:44:21 .. furthermore, you need to be the foreground tab in order to use this; otherwise it rejects immedatiatly due to no user ineraction. 17:44:44 .. if you switch away, then use another site to try to write to the clipboard; the subsequent write would kill the original. 17:45:16 BoCupp: We had one mild concern.. fast-finger copy-tab-switch-paste... 17:45:53 .. if this switch that cancels isn't fast enough... 17:46:08 whsieh: yeaaaaah, I see that. In practice, not a concern. 17:46:21 BoCupp: I like the rules you noted whsieh 17:46:46 snianu: maybe one issue with checking active document. In chromium, browser process shows a dialog. When you click OK the promise resolves. 17:47:29 .. between the time the OK is clicked, then the promise resolves, and inbetween that time the document loses focus. If the check for an active document occurs during that time, there could be a race. 17:47:37 .. might be a chromium-specific case. 17:47:49 BoCupp: for our permission dialog, I think we could ensure the scenario works. 17:48:05 .. if it was other dialogs (unbounded) that might be a problem, but might be an edge case. 17:48:16 github: https://github.com/w3c/clipboard-apis/issues/161 17:48:27 BoCupp: I think we can make it work for this case. 17:49:13 topic: editcontext api 17:49:45 AlexK: have heard some feedback from firefox, etc., but not heard anything from webkit? 17:50:04 whsieh: haven't started working on this yet, but plan to in the future some time. I think the API makes sense to us. 17:50:34 johanneswilm: in terms of W3C process? What's next? 17:50:39 BoCupp: It's an editor's draft. 17:50:53 .. next step is FPWD 17:51:13 .. masayuki opened a few issues: not sure if they've been resolved yet. 17:52:19 action: Travis or johanneswilm to put a CfC for starting a FPWD for EditContext API. 17:52:48 topic: any last comments? 17:53:56 (general discussion about video conference reliability) :) 17:57:38 https://github.com/w3c/editing/issues/359 18:05:07 github-bot: end topic 18:05:14 github-bot, end topic 18:05:28 Zakim, end the meeting 18:05:28 As of this point the attendees have been johanneswilm, GameMaker 18:05:29 RRSAgent, please draft minutes v2 18:05:29 I have made the request to generate https://www.w3.org/2021/11/12-editing-minutes.html Zakim 18:05:33 I am happy to have been of service, Travis; please remember to excuse RRSAgent. Goodbye 18:05:37 Zakim has left #editing 18:05:49 RRSAgent, make the logs public 18:05:49 I'm logging. I don't understand 'make the logs public', Travis. Try /msg RRSAgent help 18:06:40 rrsagent, make logs public 18:07:24 RRSAgent, public the logs 18:07:24 I'm logging. I don't understand 'public the logs', Travis. Try /msg RRSAgent help 18:07:29 RRSAgent, publish the logs 18:07:29 I'm logging. I don't understand 'publish the logs', Travis. Try /msg RRSAgent help 18:07:37 RRSAgent, why don't you understand me??? 18:07:37 I'm logging. Sorry, nothing found for 'why don't you understand me??' 18:07:56 RRSAgent, please draft minutes 18:07:56 I have made the request to generate https://www.w3.org/2021/11/12-editing-minutes.html Travis 18:36:56 AlexK has joined #editing