Intent to Implement and Ship: Feature detection for supported clipboard formats

603 views
Skip to first unread message

Anupam Snigdha

unread,
Sep 18, 2023, 1:12:17 PM9/18/23
to blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com

Contact emails

Explainer



Specification



Summary

Currently during async clipboard write operation, there is no way for the web authors to detect if a particular mime type is supported by the UAs or not before attempting to actually write the formats to the clipboard. This not only affects developer ergonomics as now web authors have to attempt to write to the clipboard first in order to find out whether write failed due to a particular mime type not supported by the UAs (or sometimes add version checks that are unreliable at best), but also leads to unnecessary cost in terms of CPU cycles, COGS etc in order to produce an expensive web custom format which may not be supported by a particular browser.



Blink component

Search tags

TAG review

None

TAG review status

Not applicable


WebFeature UseCounter name

kAsyncClipboardAPISupportsTypes

Risks



Interoperability and Compatibility

None

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

Existing devtools support should be sufficient to query the static method from ClipboardItem.



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?

Yes

Flag name on chrome://flags

ClipboardSupportedTypes

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

Measurement

Added usage metrics: AsyncClipboardAPISupportsTypes

Adoption expectation

Excel online is ready to use this API for adding web custom format support.

Adoption plan

Support for 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

Estimated milestones

Shipping on desktop
119
DevTrial on desktop
119
Shipping on Android
119
DevTrial on Android
119


Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Thanks,
Anupam

Sent from Outlook

Sangwhan Moon

unread,
Sep 19, 2023, 2:11:02 AM9/19/23
to Anupam Snigdha, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com
Interesting problem, never thought about this ergonomic problem.

On Sep 19, 2023, at 2:12, 'Anupam Snigdha' via blink-dev <blin...@chromium.org> wrote:



Contact emails

Explainer



Specification



Summary

Currently during async clipboard write operation, there is no way for the web authors to detect if a particular mime type is supported by the UAs or not before attempting to actually write the formats to the clipboard. This not only affects developer ergonomics as now web authors have to attempt to write to the clipboard first in order to find out whether write failed due to a particular mime type not supported by the UAs (or sometimes add version checks that are unreliable at best), but also leads to unnecessary cost in terms of CPU cycles, COGS etc in order to produce an expensive web custom format which may not be supported by a particular browser.



Blink component

Search tags

TAG review

None

TAG review status

Not applicable

Why is it not applicable? 

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

Anupam Snigdha

unread,
Sep 19, 2023, 12:25:10 PM9/19/23
to Sangwhan Moon, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com
Why is it not applicable? 
Note that this API is already in the clipboard spec and was approved by the EditingWG members. I wasn't sure if we would need TAG to review it after it was approved by representatives from Webkit, Firefox and Chromium so I didn't file a TAG review request. I can certainly do it if it's required. Please let me know.


-Anupam  

From: Sangwhan Moon <s...@chromium.org>
Sent: Monday, September 18, 2023 11:10 PM
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>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats
 
You don't often get email from s...@chromium.org. Learn why this is important

Chris Harrelson

unread,
Sep 20, 2023, 11:59:18 AM9/20/23
to Anupam Snigdha, Sangwhan Moon, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com
Please do file a TAG review and ask for official vendor signals. It's great that it was approved by the editing WG, but we also need wider TAG review for features, and WebKit and Gecko would like to see signals requests go through their official process.

Anupam Snigdha

unread,
Sep 20, 2023, 12:50:40 PM9/20/23
to Chris Harrelson, Sangwhan Moon, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com
Thanks Chris for the clarification!

Please let me know if I missed anything. Thanks!

-Anupam
From: Chris Harrelson <chri...@chromium.org>
Sent: Wednesday, September 20, 2023 8:58 AM
To: Anupam Snigdha <sni...@microsoft.com>
Cc: Sangwhan Moon <s...@chromium.org>; blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats
 

Yoav Weiss

unread,
Oct 4, 2023, 6:58:33 AM10/4/23
to blink-dev, snianu, Sangwhan Moon, blin...@chromium.org, Sanket Joshi (Edge), Evan Stade, jsb...@google.com, Chris Harrelson
Thanks for working on this! This seems like a welcome addition, and the example code of the current status quo is definitely something we need to solve!

On Wednesday, September 20, 2023 at 6:50:40 PM UTC+2 snianu wrote:
Thanks Chris for the clarification!

Thanks for filing a TAG review. I think this can benefit from a holistic view of image formats and feature detection.
E.g. do we have such feature detection for drawImage()? HTMLImageElement.decode()?  Are there other APIs that can benefit from a similar pattern? Are there reasons for these APIs to have separate feature detection methods? (i.e. do we expect support to diverge between them)

I don't have any answers, but I appreciate you thinking through these questions with the TAG and coming up with some :)


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.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.

Anupam Snigdha

unread,
Oct 5, 2023, 7:22:19 PM10/5/23
to blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
Contact emails


Explainer



Specification


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

Search tags


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.




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:

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?

Yes

Flag name on chrome://flags

ClipboardUnsanitizedContent

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug



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



Estimated milestones

Shipping on desktop
120
Shipping on Android
120


Link to entry on the Chrome Platform Status


Anupam Snigdha

unread,
Oct 5, 2023, 7:23:38 PM10/5/23
to blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
(edited the subject line)

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 Implement and Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.
 

Anupam Snigdha

unread,
Oct 5, 2023, 7:42:10 PM10/5/23
to Yoav Weiss, blink-dev, Sangwhan Moon, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Chris Harrelson
Thanks Yoav! I pinged the TAG review thread.
From: Yoav Weiss <yoav...@chromium.org>
Sent: Wednesday, October 4, 2023 3:58 AM
To: blink-dev <blin...@chromium.org>
Cc: Anupam Snigdha <sni...@microsoft.com>; Sangwhan Moon <s...@chromium.org>; blin...@chromium.org <blin...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Chris Harrelson <chri...@chromium.org>

Thomas Steiner

unread,
Oct 6, 2023, 5:54:36 AM10/6/23
to Anupam Snigdha, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
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, 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, 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?
 

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.

Anupam Snigdha

unread,
Oct 6, 2023, 1:31:52 PM10/6/23
to blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
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, 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.
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


Explainer



Specification


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

Search tags


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.




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:

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?

Yes

Flag name on chrome://flags

ClipboardUnsanitizedContent

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug



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



Estimated milestones

Shipping on desktop
120
Shipping on Android
120


Link to entry on the Chrome Platform Status


Thomas Steiner

unread,
Oct 9, 2023, 11:57:09 AM10/9/23
to Anupam Snigdha, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
As the author of the web custom formats article, 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.

Anupam Snigdha

unread,
Oct 9, 2023, 1:16:04 PM10/9/23
to Thomas Steiner, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
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 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 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
Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.
 

Thomas Steiner

unread,
Oct 10, 2023, 11:13:17 AM10/10/23
to Anupam Snigdha, Thomas Steiner, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
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 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 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!

Anupam Snigdha

unread,
Oct 10, 2023, 1:54:42 PM10/10/23
to Thomas Steiner, blin...@chromium.org, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Ana Sollano Kim
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.
 

Evan Stade

unread,
Oct 18, 2023, 10:52:14 AM10/18/23
to Anupam Snigdha, blin...@chromium.org, Sanket Joshi (EDGE), jsb...@google.com, Ana Sollano Kim
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 text to remove references to writing to avoid confusion?

-- Evan Stade

Sumeet Sharma

unread,
Oct 18, 2023, 12:54:41 PM10/18/23
to blink-dev, Evan Stade, blin...@chromium.org, Sanket Joshi (EDGE), jsb...@google.com, Ana Sollano Kim, Anupam Snigdha
I think there is also a copy-side change in that writing to the clipboard should never sanitize text/html going forward.

Anupam Snigdha

unread,
Oct 20, 2023, 1:44:41 PM10/20/23
to Sumeet Sharma, blink-dev, Evan Stade, Sanket Joshi (EDGE), jsb...@google.com, Ana Sollano Kim
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.
 
You don't often get email from sharma...@google.com. Learn why this is important

Anupam Snigdha

unread,
Oct 25, 2023, 4:33:37 PM10/25/23
to Yoav Weiss, blink-dev, Sangwhan Moon, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Chris Harrelson
I found a similar API canPlayType for media element that informs the user about the supported MIME types. So, it looks like there is some precedent for this kind of API on the web.

-Anupam

From: Anupam Snigdha <sni...@microsoft.com>
Sent: Thursday, October 5, 2023 4:41 PM
To: Yoav Weiss <yoav...@chromium.org>; blink-dev <blin...@chromium.org>
Cc: Sangwhan Moon <s...@chromium.org>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Evan Stade <est...@chromium.org>; jsb...@google.com <jsb...@google.com>; Chris Harrelson <chri...@chromium.org>
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.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.

Rick Byers

unread,
Nov 1, 2023, 11:43:48 AM11/1/23
to Anupam Snigdha, Yoav Weiss, blink-dev, Sangwhan Moon, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Chris Harrelson
LGTM1 

Philip Jägenstedt

unread,
Nov 1, 2023, 11:44:44 AM11/1/23
to Rick Byers, Anupam Snigdha, Yoav Weiss, blink-dev, Sangwhan Moon, Sanket Joshi (EDGE), Evan Stade, jsb...@google.com, Chris Harrelson
LGTM2

This looks like a small addition that we should ship. It's tested and passing here:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8SCt5_A4E9Fyu%2B_PeHbE-_vimSx8mZfXQS2F3RW5bg%2BQ%40mail.gmail.com.

Chris Harrelson

unread,
Nov 1, 2