Intent to Prototype: Delayed clipboard rendering

[Ana Sollano Kim]

Contact emails

anso...@microsoft.com, sni...@microsoft.com, sa...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/DelayedClipboard/DelayedClipboardRenderingExplainer.md

Specification

https://w3c.github.io/clipboard-apis

Summary

Delays the generation of the clipboard payload until it is needed by the target applications. Delayed clipboard rendering leverages the existing Async Clipboard API to allow web applications to improve performance when exchanging large data payloads by only producing the clipboard payload once a target application attempt to access it.

Blink component

Blink>DataTransfer

Motivation

Source applications typically don’t know where the user intends to paste the content at the time of copy, so web applications may produce several formats when writing to the clipboard to prepare for many possible target applications. The generation of one or more representations may take enough time that it is noticeable to the user, but it is unlikely that the target application will need all produced representations.

Initial public proposal

https://github.com/w3c/editing/issues/417

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Chromium is the first browser to support delayed clipboard rendering. Firefox and Safari have expressed no concerns about the concept.

Gecko: No signal (https://github.com/w3c/editing/issues/417#issuecomment-1452770119) Expressed no concerns.

WebKit: No signal (https://github.com/w3c/editing/issues/417#issuecomment-1452770119) Expressed no concerns.

Web developers: No signals

Other signals:

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?

Debuggability

The Async Clipboard API have tooling support as described in the DevTools support checklist.

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

No

Flag name

TBD

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5124936324087808

This intent message was generated by Chrome Platform Status.

 

[Ana Sollano Kim]

Sending some clarifications.

 

TAG review

Performance improvement. No change in Web APIs.

TAG review status

Not applicable

Interoperability and Compatibility

Chromium is the first browser to support delayed clipboard rendering. Firefox and Safari have expressed no concerns about the concept.

Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/758) Expressed no concerns, conversation: https://github.com/w3c/editing/issues/417#issuecomment-1452770119

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/144) Expressed no concerns, conversation: https://github.com/w3c/editing/issues/417#issuecomment-1452770119

Web developers: Positive Our partners have shown interest to leverage delayed clipboard rendering along with the Clipboard Async API's custom formats.

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.

 

Design Doc

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

[Joshua Bell]

Hey folks! This is very exciting to see. 

I notice the linked explainer is marked Archived, and links to itself as the current version? The attached design doc is helpful, but unhelpfully forbids copy/paste. Can you fix that?

The explainer calls out that there's no API change, but the design doc's example shows the ClipboardItem consuming what looks like a promise that resolves to a function... which doesn't seem to be what's intended. What's the best way for other Chromium folks to help you iterate on the explainer and API design, and provide feedback on the design doc?

Again, this is awesome to see - I've definitely heard requests for this functionality from many partners.

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

[Sangwhan Moon]

Interesting proposal! Wondering why the TAG review is marked as pending when there was no review submitted?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD649j6Cz4fUEbAK%3DRJ7to0PJ0Qp72OcSw-Au_vQZdRTS%2BC6%2Bw%40mail.gmail.com.

[Ana Sollano Kim]

Thank you for the comments!

 

• I changed the explainer to reflect the current state of that document. The one I linked is the current one.
• I updated the permissions of the design doc to allow for suggestions/comments. Feedback is very much appreciated in the google doc. We can also discuss via email or call as needed. We have an issue opened in the EWG, so that's also a good place for feedback on the explainer.
• I updated the examples on the design doc with a couple of nits.  Regarding the ClipboardItem constructor: when the promise to the function resolves into a Blob, the existing Async Clipboard API just works. Examples:

 

const promiseBlob = new Promise(generateExpensiveHTML);

 

function generateExpensiveHTML(resolve, reject) {

  const blobInput = new Blob([ '<p>Some HTML</p>'], {type: 'text/html'});

  resolve(blobInput);

     }

 

or

 

const promiseBlob = new Promise((resolve, reject) => {    

  const blobInput = new Blob([ '<p>Some HTML</p>'], {type: 'text/plain'});

  resolve(blobInput);

});

 

const clipboardItem = new ClipboardItem({'text/html': promiseBlob});

     await navigator.clipboard.write([clipboardItem]);

 

The following examples would need a change in the API in order to work.

 

1.

const promiseBlob = new Promise(generateExpensiveHTML);

const clipboardItem = new ClipboardItem({'text/html': promiseBlob});

     await navigator.clipboard.write([clipboardItem]);

 

function generateExpensiveHTML(resolve, reject) {

  const blobInput = new Blob([ '<p>Some HTML</p>'], {type: 'text/html'});

  return blobInput;

}

 

2.

const clipboardItem = new ClipboardItem({'text/html': generateExpensiveHTML});

     await navigator.clipboard.write([clipboardItem]); 

 

• On the TAG review, I updated the TAG review field to "Not applicable" since this proposal doesn't change the Async Clipboard API and is mainly a performance feature. I'm happy to initiate a TAG review if necessary. Let me know your thoughts.

 

Thanks,

Ana

 

From: Sangwhan Moon <s...@chromium.org>
Sent: Sunday, March 5, 2023 11:27 AM
To: Joshua Bell <jsb...@chromium.org>; Ana Sollano Kim <Ana.S...@microsoft.com>
Cc: blin...@chromium.org; Anupam Snigdha <sni...@microsoft.com>; Sanket Joshi (EDGE) <sa...@microsoft.com>; est...@chromium.org; etien...@chromium.org; asu...@chromium.org; dch...@chromium.org; a...@chromium.org
Subject: [EXTERNAL] Re: [blink-dev] RE: Intent to Prototype: Delayed clipboard rendering

 

You don't often get email from s...@chromium.org. Learn why this is important

[Sangwhan Moon]

If the API surface doesn't change, it's probably fine to skip the TAG review. That said, I'll skim the proposal and let you know if there is a need.

On Mar 7, 2023, at 8:21, Ana Sollano Kim <Ana.S...@microsoft.com> wrote:



[Ana Sollano Kim]

Thank you for the response. We’ll act accordingly regarding the TAG review.

 

Further clarifications on the highlighted examples. I included these just to show what currently does NOT work with the current API, but we’re not actively pursuing that and it is out of scope for this proposal.

 

Thanks,

Ana

 

From: Sangwhan Moon <s...@chromium.org>
Sent: Monday, March 6, 2023 3:47 PM
To: Ana Sollano Kim <Ana.S...@microsoft.com>
Cc: Joshua Bell <jsb...@chromium.org>; blin...@chromium.org; Anupam Snigdha <sni...@microsoft.com>; Sanket Joshi (EDGE) <sa...@microsoft.com>; est...@chromium.org; etien...@chromium.org; asu...@chromium.org; dch...@chromium.org; a...@chromium.org
Subject: Re: [EXTERNAL] Re: [blink-dev] RE: Intent to Prototype: Delayed clipboard rendering

 

You don't often get email from s...@chromium.org. Learn why this is important

If the API surface doesn't change, it's probably fine to skip the TAG review. That said, I'll skim the proposal and let you know if there is a need.

On Mar 7, 2023, at 8:21, Ana Sollano Kim <Ana.S...@microsoft.com> wrote:



Thank you for the comments!

 

1. I changed the explainer to reflect the current state of that document. The one I linked is the current one.
2. I updated the permissions of the design doc to allow for suggestions/comments. Feedback is very much appreciated in the google doc. We can also discuss via email or call as needed. We have an issue opened in the EWG, so that's also a good place for feedback on the explainer.
3. I updated the examples on the design doc with a couple of nits.  Regarding the ClipboardItem constructor: when the promise to the function resolves into a Blob, the existing Async Clipboard API just works. Examples:

 

const promiseBlob = new Promise(generateExpensiveHTML);

 

function generateExpensiveHTML(resolve, reject) {

  const blobInput = new Blob([ '<p>Some HTML</p>'], {type: 'text/html'});

  resolve(blobInput);

     }

 

or

 

const promiseBlob = new Promise((resolve, reject) => {    

  const blobInput = new Blob([ '<p>Some HTML</p>'], {type: 'text/html}); // fixed typo

[PhistucK]

I am a little confused here...

How will using a promise this way be a performance optimization? Promises run their given function immediately, so the work is being done anyway, not on demand.

Is it specifically only a potential* memory optimization (because the blob data will not be put onto the clipboard yet)?

*Potential because blobs can be represented as file system files and so the data may not be actually copied onto the clipboard anyway, only their handle will be put there (maybe this is a different optimization that is not yet implemented)

☆PhistucK

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

[Ana Sollano Kim]

Thank you for the feedback here and in the linked design document. It was a miss on our part that the function passed to the promise constructor - ie. the executor - cannot be used for delayed rendering because it is run immediately upon promise creation. As a result, we will need an API update to support delayed clipboard rendering. We’re getting feedback on how the update to web API can look like to allow delayed clipboard rendering, discussion around that can be found in the issue filed in the editing repo: Seeking feedback on delayed clipboard rendering proposal · Issue #417 · w3c/editing · GitHub. We’ll report back when we have an agreement on this.

 

Thanks,

Ana

 

From: PhistucK <phis...@gmail.com>
Sent: Tuesday, March 7, 2023 2:49 AM
To: Ana Sollano Kim <Ana.S...@microsoft.com>
Cc: Sangwhan Moon <s...@chromium.org>; Joshua Bell <jsb...@chromium.org>; blin...@chromium.org; Anupam Snigdha <sni...@microsoft.com>; Sanket Joshi (EDGE) <sa...@microsoft.com>; est...@chromium.org; etien...@chromium.org; asu...@chromium.org; dch...@chromium.org; a...@chromium.org
Subject: Re: [EXTERNAL] Re: [blink-dev] RE: Intent to Prototype: Delayed clipboard rendering

 

You don't often get email from phis...@gmail.com. Learn why this is important