Hi Anupam, I've spent an hour or so trying to follow the history of this discussion, there's obviously been a lot of debate in this space over the years. I think your answer to Thomas's question is what really clarified this specific proposal to me - you're specifically interested in the case where a native application wrote some HTML to the clipboard and a web app wants to read that without the loss of information that comes from sanitization. At the same time, this unsanitized view is already available on the legacy/synchronous DataTransfer API and so there's no new security and privacy risk here. Is that all right? If so, could you perhaps update the chromestatus motivation to make that clear please? I read that several times and struggled to really understand (perhaps it has some of the old motivation around write in there too?). Could you also update the explainer to describe the relationship with the web custom format feature and why it's insufficient here?
I see WebKit is opposed, due to them having a different (apparently entirely unspecified) model for dealing with unsanitized html in the clipboard. That's OK, we often still spec and ship things that WebKit has objections to. But is Apple's opposition the reason there's no (as far as I have found) formal spec for this? With Mozilla on board, would we need Apple's support in order to land the changes in the clipboard API spec <https://w3c.github.io/clipboard-apis/#clipboard-interface>? I don't think the explainer quite meets our bar for requiring all APIs shipped in blink to be fully specified somewhere (even if outside the normal standards track). For example, although the explainer does describe some spec changes, it looks like some of the logic is defined in terms of blink implementation details, right? Our goal with the blink launch process is to create "plausible interoperability" which means doing all the work needed (including IPR commitments) such that another implementer could easily change their mind and adopt the API. When we've hit this situation before we've relied either on 1) a formal/reviewed pull request to the spec (with preview) and an explanation for why landing the PR has been blocked, or 2) a monkey-patch spec which is still a formal spec (eg. in WICG or other incubation venue) but describes only deltas to another spec but otherwise follows standard spec conventions. I don't think we want to be in the habit of shipping APIs with only explainers and informal API definitions. Thoughts? Rick On Mon, Oct 23, 2023 at 1:28 PM 'Anupam Snigdha' via blink-dev < blink-dev@chromium.org> wrote: > Sorry, not sure why we didn't add that example in the explainer, but I > added one for read(). Thanks! > > ------------------------------ > *From:* Jonathan Hao <p...@google.com> > *Sent:* Monday, October 23, 2023 6:38 AM > *To:* blink-dev <blink-dev@chromium.org> > *Cc:* Jonathan Hao <p...@google.com>; Anupam Snigdha <sni...@microsoft.com>; > Thomas Steiner <to...@google.com>; Sanket Joshi (EDGE) < > sa...@microsoft.com>; est...@chromium.org <est...@chromium.org>; > jsb...@google.com <jsb...@google.com>; Ana Sollano Kim < > ana.soll...@microsoft.com> > *Subject:* [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read > unsanitized HTML > > You don't often get email from p...@google.com. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > Answering myself: I found an example: > https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/unsanitized-html-demo.html > > On Monday, October 23, 2023 at 12:35:21 PM UTC+1 Jonathan Hao wrote: > > I'm not sure whether I misunderstood. When I read the explainer, I didn't > see any example of using the "read()" API with the new unsanitized > options. The examples seem to be all about "write()". Could you provide > some examples to the read() API please? > > Thanks, > Jonathan > > On Friday, October 20, 2023 at 7:37:01 PM UTC+1 snianu wrote: > > *sigh*.. This I2S thread keeps getting merged into another unrelated I2S > thread, so going to start a new thread again to see if it fixes the issue > this time. Sorry for the inconvenience. > > Thanks, > Anupam > > ------------------------------ > *From:* Anupam Snigdha <sni...@microsoft.com> > *Sent:* Friday, October 20, 2023 10:44 AM > *To:* Sumeet Sharma <sharma...@google.com>; blink-dev < > blin...@chromium.org> > *Cc:* Evan Stade <est...@chromium.org>; Sanket Joshi (EDGE) < > sa...@microsoft.com>; jsb...@google.com <jsb...@google.com>; Ana Sollano > Kim <ana.s...@microsoft.com> > *Subject:* Re: [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read > unsanitized HTML and write well-formed HTML format. > > We decided to split the proposal into two separate changes as read > involves a change in the web API, but write doesn't. > So, we're going to ship the unsanitized read first, before we ship the > changes in behavior for the write method. I'll edit the Chrome status entry > to reflect this change. Thanks! > > ------------------------------ > *From:* Sumeet Sharma <sharma...@google.com> > *Sent:* Wednesday, October 18, 2023 8:06 AM > *To:* blink-dev <blin...@chromium.org> > *Cc:* Evan Stade <est...@chromium.org>; blin...@chromium.org < > blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; > jsb...@google.com <jsb...@google.com>; Ana Sollano Kim < > ana.s...@microsoft.com>; Anupam Snigdha <sni...@microsoft.com> > *Subject:* [EXTERNAL] Re: Intent to Ship: Async Clipboard API: Read > unsanitized HTML and write well-formed HTML format. > > I think there is also a copy-side change in that writing to the clipboard > should never sanitize text/html going forward. > > On Wednesday, October 18, 2023 at 10:52:14 AM UTC-4 Evan Stade wrote: > > Hi Anupam, > > I think this feature is now scoped just to the read side of the equation, > is that correct? Could you update the Chrome status entry > <https://chromestatus.com/feature/5716132676763648?context=myfeatures> text > to remove references to writing to avoid confusion? > > -- Evan Stade > > > > > ------------------------------ > *From:* Anupam Snigdha <sni...@microsoft.com> > *Sent:* Tuesday, October 10, 2023 10:54 AM > *To:* Thomas Steiner <to...@google.com> > *Cc:* blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) < > sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com > <jsb...@google.com>; Ana Sollano Kim <ana.s...@microsoft.com> > *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard > API: Read unsanitized HTML and write well-formed HTML format. > > > The code expects `text/html` at the first position of the array, but the > explainer says "If text/html representation is present in the ClipboardItem > and text/html is present in the unsanitized list", which suggests any > position would be fine. Maybe make the explainer say what the code says or > vice versa. > > Good catch. I'll edit the explainer to match the code. Thanks! > > ------------------------------ > *From:* Thomas Steiner <to...@google.com> > *Sent:* Tuesday, October 10, 2023 8:12 AM > *To:* Anupam Snigdha <sni...@microsoft.com> > *Cc:* Thomas Steiner <to...@google.com>; blin...@chromium.org < > blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan > Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana > Sollano Kim <ana.s...@microsoft.com> > *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard > API: Read unsanitized HTML and write well-formed HTML format. > > On Mon, Oct 9, 2023 at 7:15 PM Anupam Snigdha <sni...@microsoft.com> > wrote: > > Any answer on the other question regarding what the expected outcome of a > call like below would be? > > Currently we're throwing a JS exception > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/clipboard/clipboard_promise.cc;drc=c5ac981ddffb22c613baf38bf69f3554f51894d0;l=248> > if > the unsanitized list contains a format other than `text/html`. > > > The code expects `text/html` at the first position of the array, but the > explainer says "If text/html representation is present in the ClipboardItem > and text/html is present in the unsanitized list", which suggests any > position would be fine. Maybe make the explainer say what the code says or > vice versa. > > In theory we could also add other built-in formats in the future where > sanitization is needed by-default on read(), but unsanitized content is > returned if the author explicitly opts into it. e.g. For `image/svg+xml`, > we could return sanitized content by-default > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/clipboard/clipboard_writer.cc;drc=f5bdc89c7395ed24f1b8d196a3bdd6232d5bf771;l=225> > where > styles would be inlined and <meta> tags would be stripped out by the > sanitizer, but if the authors want unsanitized content, then they can > explicitly opt into it by adding this format to the unsanitized list. > > > This sounds like a feasible extension to the current behavior. > > > Probably you could even remove the "hello" in `<div > id="logDiv">hello</div>` so the DIV is entirely empty to avoid any and all > misunderstandings. > > Done. > > > Thank you! > ------------------------------ > *From:* Anupam Snigdha <sni...@microsoft.com> > *Sent:* Monday, October 9, 2023 10:15 AM > *To:* Thomas Steiner <to...@google.com> > *Cc:* blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) < > sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com > <jsb...@google.com>; Ana Sollano Kim <ana.s...@microsoft.com> > *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard > API: Read unsanitized HTML and write well-formed HTML format. > > > Any answer on the other question regarding what the expected outcome of a > call like below would be? > > Currently we're throwing a JS exception > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/clipboard/clipboard_promise.cc;drc=c5ac981ddffb22c613baf38bf69f3554f51894d0;l=248> > if > the unsanitized list contains a format other than `text/html`. In theory we > could also add other built-in formats in the future where sanitization is > needed by-default on read(), but unsanitized content is returned if the > author explicitly opts into it. e.g. For `image/svg+xml`, we could return > sanitized > content by-default > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/clipboard/clipboard_writer.cc;drc=f5bdc89c7395ed24f1b8d196a3bdd6232d5bf771;l=225> > where > styles would be inlined and <meta> tags would be stripped out by the > sanitizer, but if the authors want unsanitized content, then they can > explicitly opt into it by adding this format to the unsanitized list. > > Probably you could even remove the "hello" in `<div > id="logDiv">hello</div>` so the DIV is entirely empty to avoid any and all > misunderstandings. > > Done. > > ------------------------------ > *From:* Thomas Steiner <to...@google.com> > *Sent:* Monday, October 9, 2023 8:56 AM > *To:* Anupam Snigdha <sni...@microsoft.com> > *Cc:* blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) < > sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com > <jsb...@google.com>; Ana Sollano Kim <ana.s...@microsoft.com> > *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard > API: Read unsanitized HTML and write well-formed HTML format. > > > As the author of the web custom formats article > <https://developer.chrome.com/blog/web-custom-formats-for-the-async-clipboard-api/>, > just for me to better understand: the problem is that the clipboard gets > populated with `text/html` by random (web or native) apps. If the clipboard > were populated from the start with `web text/html`, the contents could be > read unsanitized, even without this new parameter. So this new parameter is > the escape hatch that developers can use via > `navigator.clipboard.read({unsanitized: ["text/html"]})`. > > So, the problem is that, for sites like Excel Online, they aren't sure > where the user is going to paste, so they always have to produce both 'web > text/html' and 'text/html'. That way if an app doesn't have support for web > custom format, then they can use the native HTML format. Same thing for > native apps that produce a web custom format. > There are also legacy native apps (old Office versions that are used by > Enterprises) that don't have support for the new web custom format, so the > site has to produce the standard HTML format for those apps as well. > But you are right that if both source and target apps support web custom > format, then it can be used to access unsanitized HTML content. > > > Crystal-clear now, thanks for confirming my theory. > > > An immediate question that I ask myself is whether this mechanism could be > expanded to other values than just `"text/html"`. > > Currently we are focusing on the standard HTML format to better align with > the DataTransfer APIs. In theory you could add support for other built-in > formats as well, but the main intent here is to produce similar fidelity of > HTML format so sites that use DataTransfer APIs to read HTML do not > experience any regression when they move over to async clipboard API for > copy-paste operations. > > Here is a document where I described the regressions and impact on the > apps when sanitization is performed: > https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing > > Some native apps that I surveyed for impact of this new proposal: > https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing > > > Well understand the need for HTML. > > I'm just looking at this with the eyes of a developer new to this who > might ask themselves whether they can just put something else there. It's a > generic-sounding option "unsanitized", but that is hardcoded to just > "text/html", as per the spec. Maybe it could be renamed to something very > specific like "unsanitizedHTML" and accept a boolean? > > Any answer on the other question regarding what the expected outcome of a > call like below would be? > > `navigator.clipboard.read({unsanitized: ["hahaha/lol", "text/html", > "application/json", "text/plain"]})` > > > FWIW, this demo was initially a bit misleading, since I expected "some > text" to be on the clipboard, or whatever I put into the `contenteditable` > box, but it's hardcoded. Maybe remove the box. > > Oops, sorry about that. Copy-paste error 🙂 I fixed it now. > > > Probably you could even remove the "hello" in `<div > id="logDiv">hello</div>` so the DIV is entirely empty to avoid any and all > misunderstandings. > > ------------------------------ > *From:* Anupam Snigdha > *Sent:* Friday, October 6, 2023 10:31 AM > *To:* blin...@chromium.org <blin...@chromium.org> > *Cc:* Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade < > est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano > Kim <ana.s...@microsoft.com> > *Subject:* Intent to Ship: Async Clipboard API: Read unsanitized HTML and > write well-formed HTML format. > > The I2S thread was incorrectly merged into another I2S that I sent for a > completely different feature. I'm creating a new thread and merging > replies. Sorry for the inconvenience. > > As the author of the web custom formats article > <https://developer.chrome.com/blog/web-custom-formats-for-the-async-clipboard-api/>, > just for me to better understand: the problem is that the clipboard gets > populated with `text/html` by random (web or native) apps. If the clipboard > were populated from the start with `web text/html`, the contents could be > read unsanitized, even without this new parameter. So this new parameter is > the escape hatch that developers can use via > `navigator.clipboard.read({unsanitized: ["text/html"]})`. > > So, the problem is that, for sites like Excel Online, they aren't sure > where the user is going to paste, so they always have to produce both 'web > text/html' and 'text/html'. That way if an app doesn't have support for web > custom format, then they can use the native HTML format. Same thing for > native apps that produce a web custom format. > There are also legacy native apps (old Office versions that are used by > Enterprises) that don't have support for the new web custom format, so the > site has to produce the standard HTML format for those apps as well. > But you are right that if both source and target apps support web custom > format, then it can be used to access unsanitized HTML content. > > An immediate question that I ask myself is whether this mechanism could be > expanded to other values than just `"text/html"`. > > Currently we are focusing on the standard HTML format to better align with > the DataTransfer APIs. In theory you could add support for other built-in > formats as well, but the main intent here is to produce similar fidelity of > HTML format so sites that use DataTransfer APIs to read HTML do not > experience any regression when they move over to async clipboard API for > copy-paste operations. > > Here is a document where I described the regressions and impact on the > apps when sanitization is performed: > https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing > > Some native apps that I surveyed for impact of this new proposal: > https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing > > FWIW, this demo was initially a bit misleading, since I expected "some > text" to be on the clipboard, or whatever I put into the `contenteditable` > box, but it's hardcoded. Maybe remove the box. > > Oops, sorry about that. Copy-paste error 🙂 I fixed it now. > > Please let me know if you have any questions! > > Thanks, > Anupam > ------------------------------ > *From:* Thomas Steiner <to...@google.com> > *Sent:* Friday, October 6, 2023 2:54 AM > *To:* Anupam Snigdha <sni...@microsoft.com> > *Cc:* blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) < > sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com > <jsb...@google.com>; Ana Sollano Kim <ana.s...@microsoft.com> > *Subject:* [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Async Clipboard > API: Read unsanitized HTML and write well-formed HTML format. > > > Adoption expectation > Excel online is ready to use this API. They are trying to move away from > DataTransfer APIs and use Async clipboard APIs where web custom format is > supported along with other benefits from async usage. > > Adoption plan > Support for async clipboard API and web custom format is already in inner > rings, so once this gets added to the clipboard API, Excel would be ready > to use it right away. > > > As the author of the web custom formats article > <https://developer.chrome.com/blog/web-custom-formats-for-the-async-clipboard-api/>, > just for me to better understand: the problem is that the clipboard gets > populated with `text/html` by random (web or native) apps. If the clipboard > were populated from the start with `web text/html`, the contents could be > read unsanitized, even without this new parameter. So this new parameter is > the escape hatch that developers can use via > `navigator.clipboard.read({unsanitized: ["text/html"]})`. > > An immediate question that I ask myself is whether this mechanism could be > expanded to other values than just `"text/html"`. For example, could one do > `navigator.clipboard.read({unsanitized: ["image/avif"]})` and expect it to > work (when an AVIF image is on the clipboard)? Reading the relevant > section in the explainer > <https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md#read>, > it seems hardcoded to ignore any other value than `"text/html"`, so > something like `navigator.clipboard.read({unsanitized: ["hahaha/lol", > "text/html", "application/json", "text/plain"]})` would work. Is this > correct? > > > Sample links > > https://viridian-hypnotic-cut.glitch.me/ > > > FWIW, this demo was initially a bit misleading, since I expected "some > text" to be on the clipboard, or whatever I put into the `contenteditable` > box, but it's hardcoded. Maybe remove the box. > > > ------------------------------ > *From:* Anupam Snigdha <sni...@microsoft.com> > *Sent:* Thursday, October 5, 2023 4:22 PM > *To:* blin...@chromium.org <blin...@chromium.org> > *Cc:* Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade < > est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Ana Sollano > Kim <ana.s...@microsoft.com> > *Subject:* Intent to Ship: Async Clipboard API: Read unsanitized HTML and > write well-formed HTML format. > > > Contact emails > sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org, > jsb...@chromium.org, asu...@chromium.org, *anso...@microsoft.com > <anso...@microsoft.com>* > > > Explainer > > https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md > > > Specification > > https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-unsanitized/explainer.md > > Summary > > This proposal provides an `unsanitized` option in read() method to get the > unsanitized HTML format. Unless sites explicitly opt-into reading the > unsanitized HTML, they will get the sanitized HTML content by-default. > Currently, when we read text/html MIME type using the async API, the > sanitizer is invoked to strip out contents from the HTML markup due to > security concerns, and styles are inlined into the HTML markup, which leads > to a bloated HTML payload and loss of fidelity of HTML content when read by > web authors or native apps. Firefox provides access to unsanitized HTML via > DataTransfer APIs, which matches Chromium's behavior, and Safari only > allows access to unsanitized HTML if it's being read within the same origin. > > > *Comments* > For more context on this change, here is a discussion between > stakeholders: > https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing > > > Blink component > Blink>DataTransfer > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDataTransfer> > > Search tags > *unsanitized html > <https://chromestatus.com/features#tags:unsanitized%20html>*, async api > <https://chromestatus.com/features#tags:async%20api>, clipboard > <https://chromestatus.com/features#tags:clipboard> > > TAG review > There is no desire to standardize this behavior as discussed in > https://github.com/w3c/clipboard-apis/issues/150#issuecomment-917273986. > Also, Webkit was opposed to any change in behavior since their > implementation of Async API interops with the DataTransfer API ( > https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047152542). > > TAG review status > Not applicable > > > WebFeature UseCounter name > AsyncClipboardAPIUnsanitizedRead > > Risks > > > Interoperability and Compatibility > > This is a Chromium-only feature (see discussion in > https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing), > so adding a dictionary as an argument in read will be ignored in > non-Chromium browsers and the HTML read might be sanitized. As this change > aligns the sanitization behavior of the DataTransfer API and the Clipboard > Async API, existing paste targets that support DataTransfer APIs > unsanitized HTML don't need to make updates on how they handle HTML if they > decide to transition to the Clipboard Async API. > > *Gecko*: Neutral ( > https://github.com/mozilla/standards-positions/issues/769) > https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598 > > *WebKit*: Negative ( > https://github.com/w3c/clipboard-apis/issues/150#issuecomment-974236367) > > *Web developers*: Positive. Positive signals from Excel Online, > https://groups.google.com/a/chromium.org/g/blink-dev/c/j9fDbU9E2Ds/m/IPocqIfEAwAJ?utm_medium=email&utm_source=footer > > *Ergonomics* > The spec'd read method doesn't accept any arguments. With this feature, we > have overloaded the read method in order to add a dictionary argument, > where web authors will explicitly request for the unsanitized HTML format. > > *Activation* > The current Clipboard Async API read method as specified in > https://w3c.github.io/clipboard-apis/ isn't affected by the introduction > of this feature, the behavior is validated through existing web tests. > > *Security* > Sites have to explicitly opt into reading unsanitized HTML content via the > "unsanitized" option, so any sites that don't have that option, would get > the default, sanitized HTML content. The legacy DataTransfer APIs already > allow access to unsanitized HTML content, so we don't think this will > create any additional security loopholes. > Threat Model document: > > https://docs.google.com/document/d/1QLt50Q8UnlQksVltZ2PNkDZVdk9N58Pq7P0lzGTKh-U/edit?usp=sharing > > *WebView application risks* > *Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications?* > No. > > Ergonomics > > N/A > > Activation > > N/A > > Security > > N/A > > WebView application risks > > *Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications?* > > N/A > > Debuggability > > No specific DevTools changes are required. This feature is treated like > any other JS method. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)? > Yes > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > Yes > > Flag name on chrome://flags > ClipboardUnsanitizedContent > > Finch feature name > None > > Non-finch justification > None > > Requires code in //chrome? > False > > Tracking bug > > https://bugs.chromium.org/p/chromium/issues/detail?id=1268679 > > Measurement > Added usage metrics: ClipboardUnsanitizedContent > > Adoption expectation > Excel online is ready to use this API. They are trying to move away from > DataTransfer APIs and use Async clipboard APIs where web custom format is > supported along with other benefits from async usage. > > Adoption plan > Support for async clipboard API and web custom format is already in inner > rings, so once this gets added to the clipboard API, Excel would be ready > to use it right away. > > Sample links > > https://viridian-hypnotic-cut.glitch.me/ > > Estimated milestones > > Shipping on desktop > > 120 > > Shipping on Android > > > 120 > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5716132676763648 > > Thanks, > Anupam > > Sent from Outlook <http://aka.ms/weboutlook> > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0844006CF033910582A09333CFD8A%40CH2PR00MB0844.namprd00.prod.outlook.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0844006CF033910582A09333CFD8A%40CH2PR00MB0844.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_veyZ0DxYWHgETtijf_RkMho-Kp-cbgFQ8AT0RdkqEQA%40mail.gmail.com.
