Meeting minutes
<Travis> (group does a quick round of introductions)
johanneswilm: i suggest we start with the two topics marked agenda+ in the repository
Seeking feedback on Clipboard Pickling APIs
<Travis> github: https://
bo: right now we have a GitHub issue continuing security review led by some GitHub engineers. The last consensus that we had was that we want to document a format for interchange between native apps and web application. We agreed we would write that in a non-normative note.
… we had some disagreement on the sanitization procedures for both read and write
… Our proposal has been that when we read, we could supply a new option, "unsanitize", that takes a list of content types to read without sanitization
… We maintain that it's unnecessary to sanitize on write to the clipboard. Certainly for clipboard pickling, you can't sanitize a format you don't understand. More importantly, for the well-known format text/html, we want to be able to write it unsanitized. We detailed the impact that it has on applications if we lose the fidelity of writing unsanitized HTML.
… We had resolved that we would allow user agents to sanitize or not, at the last special meeting. I don't think we have anything new.
Anne: It sounds quite bad for web developers, everything that is optional.
Wenson: it would be nice to reiterate why sanitize is necessary on read.
Bo: At least with Chromium implementation, if you Ctrl+V, if you don't do anything, we process HTML before we put it into the document. We make "insert ready" HTML.
Bo: Unlike the legacy API, that returns unsanitized content, Chromium browsers produce an insert ready fragment today. This has a side effect of degrading the fidelity of the HTML that the application can see.
… the web application for Word online is not able to change to the new API because it needs style rules inserted by MS Word. In a nutshell, supporting unsanitized is backwards compatibility.
<snianu> Some context on the HTML sanitization issue: https://
Wenson: When we shipped sanitization for clipboard, at lest for cross-origin, all data is sanitized. Including native to web app
… We have certain quirks in the algorithms for sanitization, some of them for things like MS Office, to make some workflows work.
Bo: I think it might be hard to specify the quirks we would need.
johanneswilm: The thing that you're saying about exceptions is not really accessible to developers making applications. It would be good if this doesn't just happen to work in MS Word.
Wenson: There are security goals we need to uphold, but workflows we acknowledge will be useful for unsanitized content. For those we want to expose native APIs that allow apps to expose raw content if they want to do so, knowing that it's going to be read by arbitrary web content. That is something we want to support, but I don't think we can do it and uphold security goals at the same time.
annevk: I have a question about security goals.
… say there is a cross origin exchange, web->web or native->web. Either they could agree to use a pickled type, or they could agree to opt into unsanitized behavior. I'm not sure what the difference is between using a new MIME type or a MIME type with unsanitized.
BoCupp: the difference is for native apps that are already writing the well-known HTML format, can web apps read that existing HTML. If they both opt into using text/html2, they can. But it should be acceptable for them to read text/html as they exist today.
… Native -> web, Wenson railed a concern that native apps might put in comments author metadata that might reveal private information.
Wenson: there are real world examples of this. MS Word will put a user's file paths within attributes that get copied.
johanneswilm: one question here. One example I've heard is MS word file paths and this is what all this about. But MS word is also the one application you happen to make exceptions for in the paste rules. But this affects other applications, too, right?
Wenson: that's currently the case, yes.
BoCupp: this is just a recap of the special meeting. We have scenarios we need to enable. We differ in behavior today, and we haven't come to consensus except to say this is all optional.
annevk: there was agreement to make it optional?
BoCupp: we did agree we could write "browser MAY do this".
Wenson: that is correct
annevk: that was instead of an "unsanitized" options bag that some implementation might ignore?
BoCupp: can someone propose a step for moving forward?
BoCupp: from our perspective, it's not locked down with the legacy APIs and it's unfortunate that the new APIs don't allow the same support. Our customers can't use it as it's currently authored.
annevk: I see it as Chromium has a privacy bug in its legacy APIs.
BoCupp: well, the idea that HTML as a format isn't meant to be shared with the web is strange.
Anupam: Firefox also returns unsanitized content.
… If there was privacy or security concern it's been there for decades.
<snianu> The issue that I linked above shows how FF, Chrome, Edge(old and new) return unsanitized HTML content via DataTransfer APIs.
JS API to invoke native desktop emoji picker
johanneswilm: so let's have another special meeting. And we'll move on.
<Travis> github: https://
BoCupp: we have an API to control the virtual keyboard, but on several platforms there's a separate experience to compose emojis.
… The request is a JS API to allow that to be shown.
Wenson: This does sound reasonable. On macOS, there's two different modes for the character picker. There's the window mode where it pops open, detached, and there's the second mode where it presents as a popover pointing to the insertion character.
… I was wondering if this API would allow for either presentation.
BoCupp: In Windows, for reference, we have two modes but not the same ones. One is an extra panel in the virtual keyboard and the other is an IME window.
annevk: Next steps might be to ask the reporter to do an investigation of the current situation across various systems and make an API proposal.
johanneswilm: The general problem that the reporter sees is that there is a keyboard combination to open these pickers but it's too difficult for end users to discover this.
… Instead, the web developers create, within JS, their own emoji picker.
… This makes little sense when there is a native emoji picker.
… If we do this, we should make sure that there is an emoji picker, or the web developer still has to create one.
… Could one get the browsers, on Linux, to bundle an emoji picker? Or would that be beyond what's possible?
… I don't see the point of an API to open an emoji picker only if there is one.
Olli: It would be nice to see concrete proposals here.
… There are issues of focus moving to and from the picker.
<Travis> In discourse, it was suggested: <input="emoji"> :)
<Travis> (https://
BoCupp: Why don't we take an action to pose to the issue that we'd like someone to come forward with a concrete proposal for the API. We can enumerate some of the issues we've raised here.
Action: Seeking a concrete proposal for an emoji picker API.
Eliminate insertFromComposition, deleteByComposition, and deleteCompositionText
<Travis> github: https://
johanneswilm: There were years of discussions for input events. In the end, it was implemented almost at the same time in WebKit and Chromium. WebKit implemented it the way we concluded, but Blink figured out there were parts that were difficult to implement. They couldn't implement it all.
… What we decided was to divide the specification into two levels so we could get them to implement part of it. Level 1 would contain the things that the Chromium team could implement and Level 2 would contain the proposal of what we wanted, and what WebKit implemented.
… Someone figured out that actually Chromium start implementing things from Level 2 anyway. It turned out that a lot of it was possible. Now Chromium is shipping most of Level 2 anyway, with very few exceptions related to IME.
… Now that they're almost the same, maybe we can scrap Level 1 and just have the Level 2.
… Bo did some investigation about what's possible and what's not, and suggested let's remove some input events from Safari, and we came to an agreement to mark them as optional in the spec. We merged Level 1 and Level 2 and marked three input events as optional.
… Then, Firefox has implemented it in the same way as Chromium. The representative from Firefox said we need to have a note while these are marked as optional, explaining some informative background. That's the agreement we currently have that everyone seems okay with to merge Level 1 and Level 2.
… This way, all browsers will be compliant.
BoCupp: There's a lot of differences between browsers for input events. In this one aspect, can we agree on the set of events that should exist? I think we're there with the exception of these three events. Firefox and Chrome do not dispatch these beforeinput events and Safari currently does. The PR is just about can we say that these beforeinput events MAY be dispatched.
johanneswilm: Currently, they are required. What we need consensus on is to mark them optional. You originally proposed to eliminate them?
BoCupp: That's right. But I am okay with the "MAY" keyword in there.
annevk: Why are the events problematic?
BoCupp: The sequence of events removes content from the DOM and then re-inserts it. On the Chromium side that's an unnecessary mutation. It's extra churn in the DOM. To have a special dance around the beginning and end of composition more than to mark that with events does not seem to have particular value.
My laptop just shut off without apparent reason, so you're without scribe until I boot back up.
<Travis> Note: about 5 minutes left in the meeting.
<Travis> tilgovi: thanks!
whsieh: I think there is still value in seeing text being committed at the end of the composition.
… note you can move around the "phrase" in some IMEs?
BoCupp: Yes, but the range is the entire string--not sub-sets.
… there's an initial composition range, and as you type things are changing... but the whole string is being replaced in the range.
johanneswilm: What happens when you hit a buffer limit?
BoCupp: What if you need to change the active composition range? (Not just for max limits).
… the composition ends (and re-starts).
… so any one of these ranges are sufficient.
… in Firefox, the selection is updated immediately, so you can derive it from the selection (don't need the composition events!)
… in closing: I'm OK with saying the events are optional.
… masayuki (based on his posts), thinks its ok if these are optional.
johanneswilm: I think he also wants there to be a note explaining why.
annevk: Yes, masayuki does represent Firefox on this matter.
… Want to ask whsieh (or someone else at Apple) to take a look before a decision is made.
whsieh: bo, when you want to remove the evnets, would you replace that with a regular insertText?
BoCupp: There's two beforeinput events that come at the end... one at the front.
… I would not dispatch the one before composition starts.
… each sequence of compositionupdate would be paired with an insertText...
… then the compositionend would be the end.
… also proposing removing the event that fires (only during reconversion): deleteByComposition
BoCupp: would love to have whsieh take a look and see if it could be removed...
whsieh: we've shipped this for many years--could have compat risk to remove (in Apple ecosystem).
BoCupp: likewise could be compat issues to add them :-) (in Firefox/Chromium)
annevk: See value in taking another look.
whsieh: possible to switch behavior, but we try to avoid it if possible.
johanneswilm: This was meant, in the end, to help JS editors.
snianu: EditContext has a lot more flexibility for this (it doesn't update the DOM)
BoCupp: would like to direct folks attention to an update to EditContext that is our for review.
https://
github-bot, end topic
<BoCupp> got to run for another meeting
<Travis> next meeting: November 12, 2021
(same time)