Yes, your understanding about interop fix and compat risk is correct. But I would just add one thing -- In the future, browsers shouldn't implement it without promises to Blobs and deviate from the spec. See Thomas's comment on this<https://bugs.webkit.org/show_bug.cgi?id=222262#c5> bug where the authors have to do this ugly workaround - The user activation issue is different from promises to Blobs during clipboard.write.
Are there specific WPT tests that cover the desired behavior? I couldn't find any, but I'm planning to add some tests in crrev.com/c/3169593. From: Yoav Weiss <yoavwe...@chromium.org> Sent: Thursday, September 30, 2021 12:46 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: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwpt.fyi%2Fresults%2Fclipboard-apis%3Flabel%3Dexperimental%26label%3Dmaster%26aligned&data=04%7C01%7Csnianu%40microsoft.com%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991435031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TzUUie2JL58r6%2FSauET%2BDBSRl6SEo25g%2BEzWHe0iK3I%3D&reserved=0>, there's a lot of yellow... On Wed, Sep 29, 2021 at 7:31 PM Anupam Snigdha <sni...@microsoft.com<mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fclipboard-apis%2F%23async-clipboard-api&data=04%7C01%7Csnianu%40microsoft.com%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991445025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gDQd7lQXnkrGIaF2LO%2B%2BCq6hq9ckEvD7ced2D0Sc%2FHI%3D&reserved=0>. The ClipboardItem<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fclipboard-apis%2F%23clipboarditem&data=04%7C01%7Csnianu%40microsoft.com%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991455020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=S%2FKQW1ylye%2Bv%2Blqlx5E9thjqMVd0AfeaDGE8R359lM0%3D&reserved=0> has a record of string that represents a MIME type and ClipboardItemData<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fclipboard-apis%2F%23typedefdef-clipboarditemdata&data=04%7C01%7Csnianu%40microsoft.com%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991455020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K8gWENtEswvUFkFRltXC2razJESk2e8uX4YbL6jxWQc%3D&reserved=0> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhtml.spec.whatwg.org%2Fmultipage%2Fdnd.html%23datatransfer&data=04%7C01%7Csnianu%40microsoft.com%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991465015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sTZcRjnPI%2BlHMgZ0NdvLgpa8hwwWh0jSnTWnpcwpdQM%3D&reserved=0> 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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991465015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GhFRghfldra1kE9Su7Bd4MfGaiwSfQtwg9iBXiFdtys%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<mailto:yoavwe...@chromium.org>> Sent: Wednesday, September 29, 2021 4:54 AM To: Anupam Snigdha <sni...@microsoft.com<mailto:sni...@microsoft.com>> Cc: blink-dev <blink-dev@chromium.org<mailto:blink-dev@chromium.org>>; Marijn Kruisselbrink <m...@chromium.org<mailto:m...@chromium.org>>; Bo Cupp <pc...@microsoft.com<mailto: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<mailto:blink-dev@chromium.org>> wrote: Contact emails sni...@microsoft.com<mailto:sni...@microsoft.com>, m...@chromium.org<mailto: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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991475011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4oTXus9uFVnbWAQLaPxTM3KrxmDMyPL8Tk5Vdd2ZhGg%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991485004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vk4iJO1gnVseK8rK%2FdPQPSdqJRloODbUSHx61o5dyeM%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991485004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9YsUGFr3tqis0z1uRyoHmjRbvFaxz16qeHrKbYJF10o%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991494996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8%2BO6U8ORVGceaFfkSOANwNdzb1ZI0s%2By6ChZZj%2BX36I%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991494996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iYJecepQ5zLz%2BPBOQb2ktPnA0xWgDjJJGYN3zXtXNKw%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991504990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y%2FbA%2FR0OOdLZL1NnPb7AO04LppGhLoL%2B4kgdKu%2BJLuM%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991504990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YfPYuevSzUxgqcbC%2BKpTUgdPw0o2h1%2FjUlZjLJ3ipP8%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991514986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=p0Ci35gpjnMXpYItDNXO33rMFZcenha3VqhbFidxJ1w%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991524981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3rh07nJ0XI%2Be%2BxlGDErKOKPNgaGdGenxJHq6HbqXN0g%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991524981%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2mZ8tAG8AnNszpXeISm%2F%2FCZuKdDiiWtIHjr5n8MLy%2Fo%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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991534976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qyZrFqieugDyobWqZgP185V%2BX%2Bnt6WFiSr599srwYX0%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<mailto: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%7C0796ff9361ff499639d608d983e66ccc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637685847991534976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=epzOlPGMOr%2BaZZisRS1hVEEtVe2Lpo6RpcCAkr4D1NA%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/SN6PR00MB039706AF40CC4473C431692DCFAA9%40SN6PR00MB0397.namprd00.prod.outlook.com.
