Thanks Anne and Thomas for the cross-browser context. Anupam - looking at the issue Anne posted, it seems Firefox explicitly did not <https://github.com/w3c/clipboard-apis/issues/135#issuecomment-766911850> implement this. I think it'd be interesting to get their opinions as to why, and whether we should align with the current WebKit behavior or the current Chromium one.
Anne - do y'all want to chime in here, or would a standards position issue be the best venue? On Thu, Sep 30, 2021 at 7:17 PM Anupam Snigdha <sni...@microsoft.com> wrote: > 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> > 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> > *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%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. > 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/CAL5BFfWbjf0noTnJ4nyd0g7iT82hjC6E9aREoUKBLTmNr2yQUg%40mail.gmail.com.
