OK, so let me recap my understanding: this is an interop bug fix where
we're currently not accepting Promises in the ClipboardItem constructor,
but Safari is (and we should).
There's no compat risk with existing content, as non-Promise calls get
converted into Promises. Future-compat risk exists with browsers that'd
implement Async Clipboard without this, but this intent tries to minimize
that risk.

Are there specific WPT tests that cover the desired behavior? Looking at
https://wpt.fyi/results/clipboard-apis?label=experimental&label=master&aligned,
there's a lot of yellow...


On Wed, Sep 29, 2021 at 7:31 PM Anupam Snigdha <sni...@microsoft.com> wrote:

> *That's not really an explainer. Can you expand on what this method does,
> how would the new method look like and how would developers use it?*
>
>
>
> Sorry for not being clear in my initial I2S. The change is fairly trivial
> from a developer’s perspective and has no compat risks so I wasn’t sure an
> i2S was required at all. This is one of the reasons I didn’t prepare an
> Explainer and other documentations as the changes have no impact to
> existing users of async clipboard API
> <https://w3c.github.io/clipboard-apis/#async-clipboard-api>.
>
>
>
> The ClipboardItem <https://w3c.github.io/clipboard-apis/#clipboarditem>
> has a record of string that represents a MIME type and ClipboardItemData
> <https://w3c.github.io/clipboard-apis/#typedefdef-clipboarditemdata> that
> represents Promises to Blobs corresponding to the MIME types.
>
> The current implementation of Clipboarditem’s constructor in Chromium
> takes Blobs and not Promises to Blobs which is not how it’s defined in the
> specification. ClipboardItem is only used in async clipboard API for
> reading/writing data to the clipboard. This API has been standardized and
> implemented in Chromium & Safari. This doesn’t affect existing sites that
> use DataTransfer
> <https://html.spec.whatwg.org/multipage/dnd.html#datatransfer> items for
> copy/paste scenarios.
>
>
>
> Definition of existing ClipboardItem constructor in Chromium:
>
> interface ClipboardItem {
>
>   [RaisesException] constructor(record<DOMString, Blob> items,
>
>               optional ClipboardItemOptions options = {});
>
>   readonly attribute FrozenArray<DOMString> types;
>
>
>
>   [
>
>     CallWith=ScriptState
>
>   ] Promise<Blob> getType(DOMString type);
>
> };
>
> Proposed definition of ClipboardItem constructor:
>
> interface ClipboardItem {
>
>   [RaisesException] constructor(record<DOMString, Promise<Blob>> items,
>
>               optional ClipboardItemOptions options = {});
>
>   readonly attribute FrozenArray<DOMString> types;
>
>
>
>   [
>
>     CallWith=ScriptState
>
>   ] Promise<Blob> getType(DOMString type);
>
> };
>
>
>
> Currently in Chromium, developers call the async write using the Blob type
> as shown below:
>
> const html_text = new Blob(
>
>                 ['<html><body><div>hello</div></body></html>'], {type:
> 'text/html'});
>
> const clipboard_item = new ClipboardItem({
>
>                  'text/html': html_text
>
>                });
>
> navigator.clipboard.write([clipboard_item]);
>
>
>
> With the proposed implementation, they can pass promises to Blobs as shown
> below:
>
> navigator.clipboard.write([
>
>                    new ClipboardItem({
>
>                        "text/html": Promise.resolve(new Blob(['<p
> style=\'color: red; font-style: oblique;\'>This text was copied using
> </p>'], {type: 'text/html'})),}),]);
>

Thanks for writing that down, that greatly clarifies things! :)


>
>
> *Was this change discussed in a standards venue?*
>
> This is an existing spec and have been approved by the Editing WG.
>
>
>
> *Is there compat risk here? Are developers already using the non-Promise
> method? What is it returning today?*
>
> *What should adoption patterns  to avoid risks in non-supporting browsers?*
>
> No compat risks as shown in the above examples. Developers can keep using
> the Blobs to ClipboardItem constructor. The promises would be resolved
> implicitly with my change.
>
> Non supporting browsers are not affected by this change as the
> ClipboardItem object can only be used in async clipboard APIs.
>
>
>
> *If not, it'd be good to ask for official signals:
> https://bit.ly/blink-signals
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbit.ly%2Fblink-signals&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682368655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cETjjsqyUaRocNL1QnK%2FYADWxTiFJ9Fvoe26gGDkB28%3D&reserved=0>*
>
> I’m not sure if it requires any signals as the async clipboard API is
> already in development. Browsers have to implement async clipboard APIs
> first before making any changes to Clipboarditem object. When they do
> implement this API, they should ideally follow the spec and implement a
> promise based ClipboardItem and not what is currently implemented in
> Chromium.
>
>
>
>
>
> *From:* Yoav Weiss <yoavwe...@chromium.org>
> *Sent:* Wednesday, September 29, 2021 4:54 AM
> *To:* Anupam Snigdha <sni...@microsoft.com>
> *Cc:* blink-dev <blink-dev@chromium.org>; Marijn Kruisselbrink <
> m...@chromium.org>; Bo Cupp <pc...@microsoft.com>
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add
> support for Promise to Blobs in clipboard item
>
>
>
>
>
>
>
> On Wed, Sep 29, 2021 at 3:02 AM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> Contact emails
>
> sni...@microsoft.com, m...@chromium.org
>
> Explainer
>
> https://www.w3.org/TR/clipboard-apis/#typedefdef-clipboarditemdata
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fclipboard-apis%2F%23typedefdef-clipboarditemdata&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682198754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yl7uDdsSoKFAtVj6DSk1ELjihiFt3F1ivSPgrBMURVE%3D&reserved=0>
>
>
>
> That's not really an explainer. Can you expand on what this method does,
> how would the new method look like and how would developers use it?
>
>
>
>
>
> Specification
>
> https://www.w3.org/TR/clipboard-apis/#typedefdef-clipboarditemdata
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fclipboard-apis%2F%23typedefdef-clipboarditemdata&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682198754%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yl7uDdsSoKFAtVj6DSk1ELjihiFt3F1ivSPgrBMURVE%3D&reserved=0>
>
> Summary
>
> Add promise support to `ClipboardItem` object. This helps the web author
> to call async clipboard write method without having to provide the Blob
> data synchronously. Authors can choose to resolve the promise later when
> the Blob data is available.
> Blink component
>
> Blink>DataTransfer
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EDataTransfer&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682208759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oO%2FSFBNtnKSLfV3P%2B5XtjekT8yFnVOJgocB4hGA9kwk%3D&reserved=0>
> TAG review
>
> N/A. The spec is in Working Draft state and has already been shipped by
> Apple.
>
>
>
> Was this change discussed in a standards venue?
>
>
>
>
> TAG review status
>
> Not applicable
> Risks
>
> None. Currently the API takes in a Blob type and the promise to a Blob
> would resolve implicitly which wouldn’t require any changes nor would it
> break any existing sites.
>
>
>
> Is there compat risk here? Are developers already using the non-Promise
> method? What is it returning today?
>
> What should adoption patterns  to avoid risks in non-supporting browsers?
>
>
>
> Interoperability and Compatibility
>
>
> *Gecko*: In Development(
> https://bugzilla.mozilla.org/show_bug.cgi?id=1619947
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1619947&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682368655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xXCeizVhUY6RtyyURPplt4t5ip4o4ajYrxGG1tzyYX4%3D&reserved=0>
> )
>
>
>
> It's not clear what this issue actually implements. Did they already
> implement and ship the Promise based API?
>
> If not, it'd be good to ask for official signals:
> https://bit.ly/blink-signals
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbit.ly%2Fblink-signals&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682368655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cETjjsqyUaRocNL1QnK%2FYADWxTiFJ9Fvoe26gGDkB28%3D&reserved=0>
>
>
>
>
> *WebKit*: Shipped
>
> *Web developers*: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=1014310
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1014310&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682378651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FyC4PBjSi6uilcLCzuQ43%2FDUOeHgpmDNhy%2FTBMmguIQ%3D&reserved=0>).
> This is also a highly requested feature by MS Office products.
> Debuggability
>
> The async clipboard APIs have basic tooling support as described in this
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1eJn5QIX4JFGackDYmdLxWXEmTDkSGj_ZGz5XY4uCKbY%2Fedit&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682388644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rI0dZkzNiJLTfRZZWUuVfbAQ1zlVA5v9nhJU2hh87Dw%3D&reserved=0>
> doc.
> Is this feature fully tested by web-platform-tests
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682388644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7kMR%2Fcq509r0jsf9gfnsa%2B4OnDM5hIxehyu8YG7g%2Bg0%3D&reserved=0>
> ?
>
> Yes
> Flag name
>
> None.
> Requires code in //chrome?
>
> False
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1014310
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1014310&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682398641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=avzHc%2FlddFJMjKF88i7CMmo5BRT0g8NeiNU9%2Fj0q%2BE0%3D&reserved=0>
> Estimated milestones
>
> 96
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5733949474078720
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeature%2F5733949474078720&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682398641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tmdl4Z1alApJui5k87QvzHIzzB%2FzFD%2BFV6jvFtk%2BM9o%3D&reserved=0>
>
> This intent message was generated by Chrome Platform Status
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2F&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682408632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dZ31sjCAeKgKfviU2rYtpSUFKE81EWh8Byj14cMQPmE%3D&reserved=0>
> .
>
>
>
> --
> 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/SN6PR00MB0397C14B0F073635A96B475ACFA99%40SN6PR00MB0397.namprd00.prod.outlook.com
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FSN6PR00MB0397C14B0F073635A96B475ACFA99%2540SN6PR00MB0397.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Csnianu%40microsoft.com%7C3f34562d18864e01b63e08d9833fe13b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685132682408632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fcTOB1xRVcVYwWbBsaPtsdJ90cL76AKmMwZ4uJGftTo%3D&reserved=0>
> .
>
>

-- 
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/CAL5BFfX1OBfHzKxfC49qXbw67NiFx6JkO-Af1oEM_%2B7E9CmUKA%40mail.gmail.com.

Reply via email to