Intent to prototype: Align async API read/write HTML format with DataTransfer API

[Ana Sollano Kim]

Contact emails

anso...@microsoft.com, sni...@microsoft.com, pc...@microsoft.com

Explainer

https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing

Specification

None

Summary

This proposal aligns the HTML format read/write async API with the setData/getData DataTransfer APIs. Currently, when we read/write text/html MIME types using the async API, the sanitizer is invoked to strip out contents from the HTML markup due to security concerns, and styles are inlined in the HTML. This leads to loss of fidelity of HTML content when read by web authors or native apps. 

Motivation

Using DataTransfer object’s setData and async clipboard write method, we are seeing interop differences in how the HTML content is sanitized and written to the clipboard. In Chromium, async clipboard write method clears the clipboard content first and then writes the payload which results in overwriting the previous HTML content that was inserted by authors using DataTransfer object’s setData API. It’d be beneficial for web authors if async clipboard and setData APIs provide the same HTML content during copy operation, so that round tripping is possible without any interop differences.

Moreover, creating a fragment and inlining the styles bloats the payload and strips out the custom styles inserted by sites like Excel Online that are used to preserve excel specific semantics.

Comments

Discussion between stakeholders: https://docs.google.com/document/d/1ha0pcpQsEgVGtPK8dd8N_0P1ynI7rXV7bR5ZFmOTD6Y/edit?usp=sharing 

Firefox's support: https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598 

Blink component

Blink>DataTransfer

TAG review

 

TAG review status

As this is a Chromium specific change, we don’t believe this merits TAG review. But we’re happy to file a request if API_OWNERS feel this change should have one.

Risks

 

Interoperability and Compatibility

Gecko: Positive https://github.com/w3c/clipboard-apis/issues/150#issuecomment-1031684598 

WebKit: No signal

Web developers: Positive

Debuggability

The async clipboard APIs have basic tooling support as described in https://docs.google.com/document/d/1eJn5QIX4JFGackDYmdLxWXEmTDkSGj_ZGz5XY4uCKbY/edit

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?

No

Flag name

TBD

Tracking bug

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

Estimated milestones

No milestones specified.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5716132676763648

 

[Thomas Steiner]

With the Pickling API proposal, we will be introducing a new `unsanitized` parameter in the read method so the content is round trippable i.e. read would return the content without any sanitization.

This last part is no longer true as far as I know: the `unsanitized` parameter was replaced with prepending `'web '` to the MIME type. It doesn’t change the described round-trip behavior, just needs updating in the Explainer.

--
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/MN2PR00MB046492DBF7ABFE976B948BE8FD899%40MN2PR00MB0464.namprd00.prod.outlook.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/

----- END PGP SIGNATURE -----

[Anupam Snigdha]

Just to clarify some of the points in the explainer. This proposal introduces an `unsanitized` option only in the navigator.clipboard.read() method. For write() we will always write unsanitized HTML content to the clipboard. This will align the behavior of async APIs with the DataTransfer APIs and also be backward compatible with the native apps on certain platforms like Windows that rely on this behavior. With the current sanitization in async API, copy pasting HTML content in Office native apps is broken because we remove custom styles from the HTML markup, inline styles into the fragment that increases the size of the copy payload etc when we write the HTML format to the system clipboard.

 

This proposal is a Chromium specific change because Firefox and Safari opposed to having an unsanitized option in the read() method, but they agreed to align the behavior of async APIs with DataTransfer APIs. We shipped the sanitization behavior first, so changing that would be a breaking change for us. Safari has the sanitization behavior for cross-origin copy-paste, but for same origin, they allow access to unsanitized HTML content. Safari’s async APIs behavior is aligned with the DataTransfer APIs so they don’t want to add an unsanitized option to read() method and cause backward compatibility issues. Firefox behaves the same as Chromium, but we didn’t see any support from them for adding an unsanitized option in read() method to allow web authors to access unsanitized HTML content.

Even though the usage of async read/write is low, we got feedback from security and other stakeholders that changing the behavior of the API would break the existing sites that rely on the sanitization behavior and also make the API “less secure”. Adding an option to switch between sanitized and unsanitized HTML content during read, and always writing unsanitized HTML content to the system clipboard would address both backward compatibility and security concerns.

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

 

-Anupam

[Thomas Steiner]

Just to clarify on my end, I was referring to the “Web Custom formats for Async Clipboard API” explainer (https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md). I was under the impression that this would replace the previous `unsanitized: true` flag (

https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md#alternative-considered-unsanitizedtrue).

[Anupam Snigdha]

The unsanitized option being proposed here is only for the well-known HTML format. It could be extended to other well-known formats, but for now we are focusing on the HTML format. Web custom format is unsanitized by design, so this option doesn’t affect the existing web custom formats.

[Ana Sollano Kim]

Thanks for the comments and clarifications on the feature.  

[Ana Sollano Kim]

Hi,

 

The change to introduce read/write unsanitized HTML content to/from the clipboard is still in review, not yet merged. Please see [Clipboard API] Write unsanitized HTML content to the clipboard (Ife196418) · Gerrit Code Review (googlesource.com) and [Clipboard API] Read unsanitized HTML content to the clipboard (Ifb148d27) · Gerrit Code Review (googlesource.com).

 

Thanks,

Ana

 

 

From: Michael Ford <michae...@rythan.com>
Sent: Friday, October 21, 2022 10:11 AM
To: blink-dev <blin...@chromium.org>
Cc: Ana Sollano Kim <Ana.S...@microsoft.com>; Bo Cupp <pc...@microsoft.com>; blin...@chromium.org <blin...@chromium.org>; Anupam Snigdha <sni...@microsoft.com>; tste...@google.com <to...@google.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to prototype: Align async API read/write HTML format with DataTransfer API

 

Could I get clarification on the  #clipboard-unsanitized-content  flag? When I enable this the Async API writes unsanitized html which is great but when I call the following I don't see a new html and the original "text/html" is still sanitized. I am testing against 107 beta on 10/21/2022. I have read the docs but I am unclear of the final decision/implementation. 

 

navigator.clipboard.read({
     unsanitized: true
 })

My goals is to have interop copy/paste with Excel desktop (2019) 

 

Thanks

[Thomas Steiner]

This is what is implemented in Chrome: 

https://developer.chrome.com/blog/web-custom-formats-for-the-async-clipboard-api/. 

[Michael Ford]

Thank you and thank you again for the quick response.

[Michael Ford]

Could I get clarification on the  #clipboard-unsanitized-content  flag? When I enable this the Async API writes unsanitized html which is great but when I call the following I don't see a new html and the original "text/html" is still sanitized. I am testing against 107 beta on 10/21/2022. I have read the docs but I am unclear of the final decision/implementation. 

navigator.clipboard.read({
     unsanitized: true
 })

My goals is to have interop copy/paste with Excel desktop (2019) 

Thanks

On Thursday, July 14, 2022 at 1:15:29 PM UTC-4 Ana Sollano Kim wrote:

[Michael Ford]

Thomas

I read the web-custom-formats and this is a very nice addition but doesn't quite solve my exact problem of interop with desktop applications. Specially Microsoft, Adobe, and other desktop products copy unsanitized html to the clipboard and I need to be able to access this content via touch and toolbar buttons. The web-custom-formats would require these desktop applications to change and then migrate their user base to these versions (assuming they even want to prioritize web interop).

Once unsanitized html is supported then the Async clipboard will have parity with the deprecated datatransfer api I can remove the the doCommand('copy') and the 'onPaste' event listener.