Intent to Ship: Pickling for Async Clipboard API

[Anupam Snigdha]

Contact emails

sni...@microsoft.com, m...@chromium.org, pc...@microsoft.com

Explainer

https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#pickling-for-async-clipboard-api

Specification

https://github.com/w3c/clipboard-apis/pull/162

https://github.com/w3c/clipboard-apis/pull/158

Design docs

https://docs.google.com/document/d/1afc45MQuwxEWgoUeJCO-sOWRSzs31V4JS-kKXJNMTXw/edit

Summary

Pickle Clipboard API lets websites read and write arbitrary unsanitized payloads using a standardized pickling format, as well as read and write a limited subset of OS-specific formats (for supporting legacy apps). The name of the clipboard format is mangled by the browser in a standardized way to indicate that the content is from the web, which allows native applications to opt-in to accepting the unsanitized content.

 

Blink component

Blink>DataTransfer

Search tags

pickle, pickling api, pickling, clipboard custom format

TAG review

https://github.com/w3ctag/design-reviews/issues/636

TAG review status

Issues addressed

Risks

 

Interoperability and Compatibility

Other browsers implement an ability to write custom clipboard data in varied shapes. Part of the value of this work is to standardize the names of the formats that will be written per platform and to ensure a common shape of data on the clipboard so that browsers can read and write from this standard set of pickled formats.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/525)

WebKit: Neutral (https://github.com/w3c/editing/issues/334#issuecomment-933939592) Webkit has a custom format implementation which isn't well documented.

Web developers: Positive (https://github.com/w3ctag/design-reviews/issues/636#issuecomment-854038820) Positive signal from Figma & Sketchup. Internal MS office products have shown interest in supporting this API.

Other signals:

Ergonomics

This feature is part of the existing async clipboard read/write. It doesn't affect the well-defined formats that are supported by this API.

 

Activation

The feature uses the existing async clipboard read/write methods which has already been shipped.

 

Security

Here is a link to a more detailed security review: https://github.com/w3c/editing/issues/315

 

Debuggability

The async clipboard APIs have basic tooling support as described in the DevTools support checklist doc.

 

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/clipboard-apis?label=master&label=experimental&aligned&q=async%20clipboard

https://wpt.fyi/results/clipboard-apis/async-custom-formats-write-read.tentative.https.html?label=master&label=experimental&aligned&q=async%20clipboard

Flag name

ClipboardCustomFormats

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=106449

Sample links

https://glitch.com/edit/#!/sequoia-innovative-date

Estimated milestones

98

 

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5649558757441536

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Lo7WBM_v_LY/m/LncCKkXeAwAJ?utm_medium=email&utm_source=footer

This intent message was generated by Chrome Platform Status.

 

[Philip Jägenstedt]

Hi Anupam,

I see that the two pull requests on the spec are still open:

https://github.com/w3c/clipboard-apis/pull/158

https://github.com/w3c/clipboard-apis/pull/162

I see there's a lot of discussion on both, with folks from other vendors involved, and it looks like some points are contentious. Can you summarize the state of things as they are, and what you think the remaining steps are to landing the spec changes?

On the testing front, is async-custom-formats-write-read.tentative.https.html the only test for this? This test doesn't seem to cover what happens writing both text/plain and custom payload, and what then happens if pasting that with and without opting into the custom format. Can these tests be made more elaborate?

Best regards,

Philip

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0397FE5D4193AD46D210F220CF9B9%40SN6PR00MB0397.namprd00.prod.outlook.com.

[Manuel Rego Casasnovas]

On 18/11/2021 22:30, 'Anupam Snigdha' via blink-dev wrote:
> /WebKit/: Neutral
> (https://github.com/w3c/editing/issues/334#issuecomment-933939592
> <https://github.com/w3c/editing/issues/334#issuecomment-933939592>)

> Webkit has a custom format implementation which isn't well documented.

I'd say: "No signal", as there's no reply to the mailing list request:
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031855.html

It would be nice to send a new email to notify the intention of shipping
in Chromium, to see if we can get any feedback there.

Cheers,
Rego

[Philip Jägenstedt]

Note that there's plenty of engagement on the repo, however. I don't
know how to summarize it, but it's clear there's disagreement on some
aspects at least.

Best regards,
Philip

[Anupam Snigdha]

Hi Philip,

 

Sorry for the delayed response. Sure, I can summarize the discussions both in the PR and the Github issues mentioned in the thread.

 

https://github.com/w3c/clipboard-apis/pull/158

 

This PR is essentially a rewrite of async clipboard API. Since the specification had lot of details missing on the ClipboardItem object and Navigator.Clipboard methods, we decided to work on this first before making any additional changes to the spec. Domenic and mbrodesser have been reviewing my changes(thank you for that!) and I think the spec is now in a pretty good state and should be ready to land soon.

 

https://github.com/w3c/clipboard-apis/pull/162

 

This PR adds an `unsanitized` option to the ClipboardItemOptions dictionary which will be used to read/write unsanitized custom formats to the system clipboard. This is the custom formats support that we want to add to the async clipboard API. The contention is mainly on the usage of the `unsanitized` option. When web developers provide formats that they want the browsers to write to the clipboard without any sanitization, the `unsanitized` option helps us to determine which formats to pickle and add to the Web Custom Format Map. If a site wants to read a custom format or an unsanitized version of the standard format, then it needs to add those formats to the unsanitized list. If native apps want to read a custom format, then they have to query the Web Custom Format Map first in order to get the custom format corresponding to the MIME type, and use that to query the system clipboard to fetch its content. The explainer has some examples as to how the web devs can read/write unsanitized custom formats, and how native apps can parse the Web Custom Format Map.

 

On Safari, the formats are always pickled so the need for unsanitized option is unnecessary on write. For read, Safari only provides access to the pickled formats if it is queried within the same origin. That limits the scope of the pickled formats read/write --  Native apps wouldn’t be able to access the custom formats written by the web apps, and web apps wouldn’t be able to access the custom formats if they are read from a different origin. We discussed extensively with the Editing WG members and Apple devs were opposed to providing access to the custom formats via the unsanitized option. They want to provide a new OS clipboard platform API which native apps would have to use to explicitly query the custom formats. That apparently is a better option(in terms of security/privacy) than native apps explicitly adding code to access the custom formats from the clipboard without requiring to implement yet another platform API to read/write content from/to the clipboard, so we disagree with this approach. Moreover, this isn’t something that we as browser developers have control over as adding an OS API is just not feasible for us, and we don’t see the need to add a new platform API to read/write custom formats to the clipboard when the existing clipboard platform APIs provide read/write access to platform defined clipboard formats and custom formats defined by the native apps.

 

We think that the unsanitized option is required for security as well as for performance reasons. It indicates explicitly which formats to pickle i.e. read/written without any sanitization process. The standard formats are always sanitized by default, so reading without the unsanitized option will return a sanitized version of the standard format. For custom formats web authors have to explicitly provide that in the unsanitized list that is passed in the read method call, which is a strong indication that they are aware of the security implications and know how to parse the content of the custom formats.

 

We have been experimenting this API with the Excel native/web app devs and have received lot of positive feedback. Excel has implemented a custom workbook format that provides copying and pasting of rich content such as charts, Excel formulas, Word/Excel specific table/list semantics etc. This feature requires changes  to the native app as well in order to read/write web custom formats, so we discussed the native format structure with the Editing WG members and didn’t see any opposition. TAG members were also satisfied with the proposal.

 

I’m working on adding more WPT tests in this CL: https://chromium-review.googlesource.com/c/chromium/src/+/3292370.

 

Thanks,

Anupam

[Sean Voisen]

Happy to see movement on this. Just a note to say that we would like to use this feature at Adobe, and would be interested in using it in Photoshop Web, Creative Cloud Canvas, and potentially other future web initiatives, particularly for interop with our desktop applications. (With the understanding, of course, that said applications would have to be updated to read the custom web format map.)

Sean

[Abhishek Rathi]

At Excel Online, we tried this in our dev environments have seen significant improvement in Copy Paste fidelity from desktop apps. This will improve user experience especially for app specific features like formulas, tables, etc.

[Alex Russell]

Thanks for the feedback, Sean and Abishek.

Sounds like strong developer support; hoping this will get resolved this week.

[Yoav Weiss]

Reading through the issues, I saw this comment, which suggests that the `unsantizied` option would be removed. That change is not yet reflected in the explainer, and seems like a big change.

Can you outline the plan?

[Daniel Bratell]

One idea I have here is that unless everyone agrees to a plan, this might be suitable for an origin trial. That would allow the major sites that have said they want this to try it out without locking ourselves into a certain API shape.

/Daniel

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/339fdf22-0449-4c3f-8d8e-f938a8f103e1n%40chromium.org.

[Anupam Snigdha]

Hi Yoav,

 

That comment is specifically for adding the `unsanitized` option to the clipboard API spec to which Apple opposed as they don’t want to support(at least currently) reading/writing custom format or unsanitized well-known format if it’s not within the same origin. That means, exchanging custom pickled formats between web app & native app wouldn’t be supported on Safari. We think that this scenario is essential for unlocking high fidelity copy/paste scenarios for native/web apps developers. The `unsanitized` option is required if we want to support reading the standard MIME types (text/html, image/png etc) from the pickled format map which would return the unsanitized version of the format. Currently, there is no way for us to differentiate between reading the standard MIME types from well-known native formats and pickled format map without the `unsanitized` option, so we decided to add this option to the `ClipboardItemOptions` dictionary that would be available only on Chromium browsers.

 FWIW there is already an option in `ClipboardItemOptions` that is very specific to iPadOS/iOS and it’s only supported in Safari: https://github.com/w3c/clipboard-apis/pull/162#issuecomment-974334049. I’m not even sure how this option was able to make it to the spec, but we certainly would have opposed to this change.

Please let me know if you have any other concerns/questions.

 

Thanks,

Anupam

[Anupam Snigdha]

Re origin trial: We did discuss about origin trials, but we are not anticipating any changes to the web API. Note that `unsanitized` option is a member of `ClipboardItemOptions` dictionary and we are not changing the shape of the existing read/write methods.

Also, since this feature would benefit a lot from changes in the native apps, we want to commit to the native format naming/structure for pickled format map. Native apps like Office have a different release cycle (depending on whether it is enterprise or not, it would vary a lot), and it’ll be really hard for them to make any changes if we decide to change either the naming or the JSON like structure of the format map.

 

From: Daniel Bratell <brat...@gmail.com>
Sent: Wednesday, December 15, 2021 8:40 AM
To: Yoav Weiss <yoav...@chromium.org>; blink-dev <blin...@chromium.org>
Cc: Alex Russell <sligh...@chromium.org>; Abhishek Rathi <rat...@gmail.com>; svo...@gmail.com <svo...@gmail.com>; Anupam Snigdha <sni...@microsoft.com>; ajayra...@google.com <ajayra...@google.com>; Bo Cupp <pc...@microsoft.com>; m...@google.com <m...@google.com>; Joshua Bell <jsb...@chromium.org>; Victor Costan <pwn...@chromium.org>; Scott Low <sc...@microsoft.com>

[Philip Jägenstedt]

Hi Anupam,

It sounds like https://github.com/w3c/clipboard-apis/pull/162 is blocked on the objections, and thus the `unsanitized` option won't be in https://w3c.github.io/clipboard-apis/. If we ship this, will it be defined by any spec? Is it an option to take this proposal to the WICG? Although we ship things while spec PRs are open sometimes, when there's no expectation that the PR can be merged, I think we need to find an alternative place for it.

Best regards,

Philip

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0397C21E7158CFA831D5293FCF769%40SN6PR00MB0397.namprd00.prod.outlook.com.

[Anupam Snigdha]

Hi Philip,

Yes,  https://github.com/w3c/clipboard-apis/pull/162 is blocked on adding the `unsanitized` option to the clipboard API spec. Since we cannot come to an agreement, we decided to write up an article about it and publish it either in EditingWG or WICG. We want to write something in the clipboard API spec about the native custom format map and how that would be parsed by native apps in specific platforms , so I'll remove the `unsanitized` option from the spec PR and just add this info as non normative notes because Apple is still opposed to standardize any native clipboard formats in a web spec -- They want this to be defined by the OS.

Thanks,

Anupam

---

From: Philip Jägenstedt <foo...@chromium.org>
Sent: Thursday, December 16, 2021 7:12 AM
To: Anupam Snigdha <sni...@microsoft.com>
Cc: Daniel Bratell <brat...@gmail.com>; Yoav Weiss <yoav...@chromium.org>; blink-dev <blin...@chromium.org>; Alex Russell <sligh...@chromium.org>; Abhishek Rathi <rat...@gmail.com>; svo...@gmail.com <svo...@gmail.com>; ajayra...@google.com <ajayra...@google.com>; Bo Cupp <pc...@microsoft.com>; m...@google.com <m...@google.com>; Joshua Bell <jsb...@chromium.org>; Victor Costan <pwn...@chromium.org>; Scott Low <sc...@microsoft.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

 

[Chris Harrelson]

Hi Anupam,

Happy new year.

When you say "article" in WICG or EditingWG do you mean spec? If so, that sounds fine.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0391DCA80B2EE3D11F05936ACF789%40DM5PR00MB0391.namprd00.prod.outlook.com.

[Anupam Snigdha]

Hi Chris,

 

Happy new year to you too 😊. Yes, the text would be in spec language, but it won’t be part of the clipboard API spec (at least for now). I’m almost done with the changes. Will upload it to EditingWG by today EOD.

I’ve also addressed all comments on the async API PR, but it is unrelated to pickling. This PR addresses all concerns about the async clipboard API spec in general.

 

Thanks,

Anupam

[Anupam Snigdha]

Here is the PR for pickling API: https://github.com/w3c/editing/pull/383

[Domenic Denicola]

On Wed, Jan 5, 2022 at 9:01 PM 'Anupam Snigdha' via blink-dev <blin...@chromium.org> wrote:

Here is the PR for pickling API: https://github.com/w3c/editing/pull/383

Note that unfortunately the most important part of the spec is left to the implementation: i.e., what to do for non-text data types being written to the clipboard. (Ctrl+F for "This is left to the implementation..." in https://github.com/w3c/editing/pull/383/files .) If I understand correctly, that is what pickling is all about, so I'm not sure pickling actually has an interoperably-implementable specification...

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0397684F4239584B6903C5BECF4C9%40SN6PR00MB0397.namprd00.prod.outlook.com.

[Anupam Snigdha]

Hi Domenic,

 

I haven’t changed that part of the algorithm as I’m still working on the async API PR. Once that PR is completed, I’ll fill in all the missing steps in the async clipboard API algorithms that are applicable for pickling. I have added all the algorithms needed to read/write custom formats and the unsanitized option that we introduced in the ClipboardItemOptions dictionary. Note that the sanitized copy part is still left up to the implementors as we couldn’t come to an agreement in EditingWG.

 

-Anupam

[Domenic Denicola]

On Thu, Jan 6, 2022 at 1:24 PM Anupam Snigdha <sni...@microsoft.com> wrote:

Hi Domenic,

 

I haven’t changed that part of the algorithm as I’m still working on the async API PR. Once that PR is completed, I’ll fill in all the missing steps in the async clipboard API algorithms that are applicable for pickling.

Thanks for the clarification. It was confusing since your message said "here is the PR for the pickling API" but I guess it did not actually include the pickling parts yet!

 

I have added all the algorithms needed to read/write custom formats and the unsanitized option that we introduced in the ClipboardItemOptions dictionary. Note that the sanitized copy part is still left up to the implementors as we couldn’t come to an agreement in EditingWG.

I think it's still important to write a spec somewhere, even if the EditingWG does not host it. See https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines for more on why specifications are important even if they're not standards.

[Anupam Snigdha]

Re: “but I guess it did not actually include the pickling parts yet!”: It does include the pickling parts. See the unsanitized option in the ClipboardItemOptions dictionary, write unsanitized format, os specific custom map name and os specific custom name sections in the PR for more details.

 

The part that is missing is the one that you mentioned “what to do for non-text data types being written to the clipboard. (Ctrl+F for "This is left to the implementation..." in https://github.com/w3c/editing/pull/383/files .) ”

 

“I think it's still important to write a spec somewhere, even if the EditingWG does not host it” – We will be merging this into the Editing repo, but it wouldn’t be part of the official clipboard API spec due to disagreement with Apple. Looks like FF is also interested in standardizing the sanitization behavior because the legacy DataTransfer APIs behave the same in Chromium, FF, old Edge and IE, but since Apple opposed to these changes we couldn’t include it in the official clipboard API spec.

[Philip Jägenstedt]

Hi Anupam,

Could https://w3c.github.io/gamepad/extensions.html be a model to follow here? I think it's important to write down (and test) what you intend to ship in something that looks like a spec. If doing that in the EditingWG doesn't seem tractable, then the WICG is also an option.

This seems like a fairly frustrating situation, but I hope it's clear what to try next. If you do feel like you're stuck with what to do with the spec, feel free to ask for advice here or off list.

Best regards,

Philip

[Anupam Snigdha]

Hi Philip,

 

In the worst case we will be able to merge the pickling API changes into the EditingWG repo. We have a meeting this Friday with the Firefox folks to discuss the Pickling API as they were also interested in the proposal. If we have consensus there, then we will be able to add pickling API to the official clipboard spec.

Overall I think the algorithms required to implement Pickling API is included in the forked PR. There are few concerns regarding sanitization, but we couldn’t come to an agreement with Apple folks to standardize it. Moreover all browsers have different sanitization behavior in the clipboard copy/paste methods so it will be hard to change anything there without breaking the legacy DataTransfer APIs that use the same sanitization algorithms.

 

Thanks,

Anupam

[Yoav Weiss]

On Wed, Jan 12, 2022 at 8:33 PM Anupam Snigdha <sni...@microsoft.com> wrote:

Hi Philip,

 

In the worst case we will be able to merge the pickling API changes into the EditingWG repo. We have a meeting this Friday with the Firefox folks to discuss the Pickling API as they were also interested in the proposal. If we have consensus there, then we will be able to add pickling API to the official clipboard spec.

Overall I think the algorithms required to implement Pickling API is included in the forked PR. There are few concerns regarding sanitization, but we couldn’t come to an agreement with Apple folks to standardize it.

Regardless of venue and consensus, it seems important that you'd have a spec that clearly outlines what you are trying to ship here, so that if and when other vendors would like to follow (e.g. you mentioned Firefox are interested in following) they would be able to.

[Yoav Weiss]

Friendly ping! :) Also happy to discuss off-thread in case it's helpful.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/339fdf22-0449-4c3f-8d8e-f938a8f103e1n%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0397C21E7158CFA831D5293FCF769%40SN6PR00MB0397.namprd00.prod.outlook.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0391DCA80B2EE3D11F05936ACF789%40DM5PR00MB0391.namprd00.prod.outlook.com.

--
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+unsubscribe@chromium.org.

[Anupam Snigdha]

Discussed offline. Sorry for the delay in response. We are reviewing Mozilla’s feedback on the proposal so I think we can put this intent on hold for now.

 

Thanks,

Anupam

 

From: Yoav Weiss <yoav...@chromium.org>
Sent: Wednesday, February 2, 2022 2:26 AM
To: blink-dev <blin...@chromium.org>

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/339fdf22-0449-4c3f-8d8e-f938a8f103e1n%40chromium.org.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0397C21E7158CFA831D5293FCF769%40SN6PR00MB0397.namprd00.prod.outlook.com.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0391DCA80B2EE3D11F05936ACF789%40DM5PR00MB0391.namprd00.prod.outlook.com.

--
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+...@chromium.org.

[Anupam Snigdha]

Reviving this thread and restarting the I2S process for this API….

Sorry for the delay here. We’ve been discussing the new proposal with EditingWG members and with our partners. We agree with Firefox’s proposal to use “web “ prefix for web custom formats instead of the unsanitized option. It makes the API more ergonomic and helps in interop across apps which is one of the benefits of using web custom formats.

We have support from other browser vendors as well(https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1047065265, https://github.com/w3c/clipboard-apis/issues/165#issue-1117218251).

I’ll try to summarize the changes here.

• We removed the `unsanitized` option from ClipboardItem constructor and read() method call.
• We’re adding support to read/write MIME types that have “web “(“web” followed by U+0020 SPACE) prefix. These special formats would be read/written unsanitized from/to the system clipboard. It will follow the platform specific clipboard format naming convention that we previously proposed for pickling: https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#os-interaction-format-naming.
• Web authors have access to both web custom format(which is unsanitized) and well-known formats(which is sanitized for text/html) during read(). In the previous proposal, unsanitized option controlled access to pickled formats, so if web authors provided well-known MIME types in the unsanitized list, then they only get access to custom unsanitized formats for the well-known mime types, and not the sanitized(for text/html) version for these mime types.
• We’re adding transient user activation as a requirement for reading/writing all supported formats in the async clipboard API. The transient user activation requirement is something that affects the existing formats. We’ve added histograms to check if site is calling the async API without transient user activation. We don’t anticipate any issues with this extra check because we don’t expect the site to read clipboard data without any user interaction as that would be a severe security/privacy issue. We discussed this in the EditingWG meeting and everyone agrees that this check should be a strict requirement to access system clipboard. Here is the relevant issue and EditingWG meeting notes: https://github.com/w3c/clipboard-apis/issues/75#issuecomment-1088932790 & https://github.com/w3c/clipboard-apis/issues/75#issuecomment-1125148793.
• We’ve updated the spec, explainer and the current implementation. Spec: https://github.com/w3c/clipboard-apis/pull/175, Explainer: https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#web-custom-formats-for-async-clipboard-api, CL: https://chromium-review.googlesource.com/c/chromium/src/+/3650952

 

Please let us know if you have any questions/concerns.

 

Thanks,

Anupam

[Alex Russell]

It's great to see all of this progress and the updated explainer is very clear.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/339fdf22-0449-4c3f-8d8e-f938a8f103e1n%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0397C21E7158CFA831D5293FCF769%40SN6PR00MB0397.namprd00.prod.outlook.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0391DCA80B2EE3D11F05936ACF789%40DM5PR00MB0391.namprd00.prod.outlook.com.

--
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+unsubscribe@chromium.org.

[Yoav Weiss]

LGTM2

Thanks for working with other vendors and significantly reducing the interop risk here! :)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/339fdf22-0449-4c3f-8d8e-f938a8f103e1n%40chromium.org.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0397C21E7158CFA831D5293FCF769%40SN6PR00MB0397.namprd00.prod.outlook.com.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0391DCA80B2EE3D11F05936ACF789%40DM5PR00MB0391.namprd00.prod.outlook.com.

--
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+...@chromium.org.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3TOEkmF%2BDpLX6zjHs1j%2Bp%2Bo6QHY6SCyv_vi-59a_g7w%40mail.gmail.com.