I'm not sure why this API needs to exist. It used to be the case that you could not write to the clipboard after await in Chrome. That's because after an await it was no longer in a synchronous user input trigger, and so the call was blocked.
User Activation v2 fixed that. Now you can write to the clipboard after await in Chrome, because the User Activation v2 rules mean you get a 1 second timeout during which you can write to the clipboard. So long as the async code runs quickly (and it almost always will if you're just doing something like reading a Blob), then everything works. Safari and Firefox don't support User Activation v2, so still have the original problem. It appears this proposal aims to solve the same problem that User Activation v2 does. IMO it would be better if Safari and Firefox just support User Activation v2 as well. Assuming a browser supports UAv2, the only benefit this API would appear to bring, is the ability to write to the clipboard beyond the 1 second deadline. If the deadline is unlimited, then this effectively grants the web page permission to write to the clipboard *at any time* after the first copy operation. Is the intent of this API really just to allow an unlimited deadline? Aren't there ways that could be abused? On Thu, 21 Oct 2021 at 10:21, Yoav Weiss <yoavwe...@chromium.org> wrote: > LGTM1 to ship conditional that y'all continue to work on PR #158 > <https://github.com/w3c/clipboard-apis/pull/158> specifically, and > clarifying the spec's processing model in general. > > On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote: > >> Gentle ping as the branch cutoff date for 97 is pretty close. While I >> agree that the issues related to clipboard API spec need to be addressed, I >> don’t think this feature needs to be blocked on that. It’s not a breaking >> change i.e. sites can continue to use Blobs if they want to(although I >> don’t think any developer would want to have different codepaths for Apple >> and Chromium browsers) >> > > FWIW, I got curious RE why that *should* work, and did some digging. > It seems like the bindings methods that accept a `Promise<T>` input value > call `NativeValueTraits<IDLPromise> > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/native_value_traits_impl.h;l=775?q=ArgumentValue&ss=chromium%2Fchromium%2Fsrc>` > on that value, which casts > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/bindings/core/v8/script_promise.cc;drc=ac35167cc1cf9c40778c1e1d8855fd90a90f0fbf;l=291> > the value foo into a `Promise.resolve(foo)`, if it wasn't a Promise already. > The same seems to work in WebKit as well. Do you know if this bindings > behavior is specified? > > Also, can you add tests for both input cases as part of your CLs for this? > > , and Apple has already shipped this feature. Please let me know in case >> of any concerns. >> >> >> >> -Anupam >> >> >> >> *From:* Anupam Snigdha >> *Sent:* Thursday, October 7, 2021 9:53 AM >> *To:* 'Yoav Weiss' <yoavwe...@chromium.org> >> *Cc:* ann...@annevk.nl; blink-dev@chromium.org; 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 >> >> >> >> Yep, I’ll address the feedback from Anne and mbrodesser (from Mozilla). >> >> Thanks for all your help Anne and Yoav! >> >> >> >> *From:* Yoav Weiss <yoavwe...@chromium.org> >> *Sent:* Thursday, October 7, 2021 12:03 AM >> *To:* Anupam Snigdha <sni...@microsoft.com> >> *Cc:* ann...@annevk.nl; blink-dev@chromium.org; 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 >> >> >> >> >> >> >> >> On Tue, Oct 5, 2021 at 4:02 AM Anupam Snigdha <sni...@microsoft.com> >> wrote: >> >> Here is a WIP PR to address the spec issue: >> https://github.com/w3c/clipboard-apis/pull/158 >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fpull%2F158&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187674892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I%2Byq6TluT%2FvAEsIdktzvyZdjjPo7TpER2cKREBGWXIU%3D&reserved=0> >> . >> >> >> >> Can you address feedback from Anne on the PR? >> >> >> >> >> >> *From:* Anupam Snigdha >> *Sent:* Monday, October 4, 2021 10:45 AM >> *To:* 'Yoav Weiss' <yoavwe...@chromium.org>; Anne van Kesteren < >> ann...@annevk.nl> >> *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 >> >> >> >> For #1: I don’t think we would want to diverge from the spec. There is a >> reason why we have promises to Blobs and not just Blobs in the >> ClipboardItem because, well, not having promises defeats the purpose of >> having an async API. Also waiting for the Blob data synchronously without >> triggering the clipboard write operation leads to problems like this >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1014310%23c15&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187684884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iddzqlsIiKiAtqUdEVzIjBylct%2B%2FpJvj%2BMzNxpFUCOM%3D&reserved=0> >> and performance issues in sites like Excel Online where the copy payload is >> in MBs. >> >> >> >> That makes sense. >> >> >> >> >> >> For #2: This might sound more of a rant so apologies in advance. >> >> >> >> I agree with Anne that the spec is not really clear at all on the >> specifics of the async clipboard API and some of the terminologies used in >> the algorithms. >> >> However, making changes to the spec or even clarifying the language after >> an API has been shipped, is really hard, as we need to get consensus from >> all browser vendors. >> >> I tried to clarify what “sanitization” means just for the HTML format >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fissues%2F150%23issuecomment-909405090&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187684884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=afRGpVd6zwD8RiSoxTnjy6mNgbGIk8iA%2F%2B6AMiCO%2BI8%3D&reserved=0> >> and Apple opposed to this change >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fissues%2F150%23issuecomment-922211803&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187694894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NfBuFjZ5mKP84MIG2AxKo8P6EmeKC5cQE6Lm%2B4cWdN0%3D&reserved=0>. >> >> >> >> >> That's unfortunate :/ >> >> >> >> Perhaps I can add a non-normative note which would at least give some >> clarity on the sanitization process, but that would probably require UA >> specific non normative notes which defeats the purpose of standardization. >> >> I also tried to make changes to address Mozilla’s concern about mandatory >> data types supported by async clipboard APIs: >> https://github.com/w3c/clipboard-apis/pull/155 >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fpull%2F155&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187694894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mrNE%2BCIsRJWBmnbUjpeQqhZ5SJeFYI9bhskywXzCuEQ%3D&reserved=0>, >> but this PR has been sitting for almost a month now and I’m not able to >> make any progress. >> >> >> >> FWIW, it seemed to have made some progress initially and then stalled. >> Pinging it may make sense. >> >> >> >> >> >> In order to make progress on spec changes, we decided to have a >> discussion with the Editing WG members and submit changes to the spec if no >> one objects to it. Currently the Editing WG has representatives from Apple >> and MS who regularly attend the monthly status meetings. So my question is, >> if we get an approval from the WG, then does that meet the minimum bar to >> make spec changes? >> >> >> >> That's for the Editing WG to decide. Looking at its charter >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2021%2F06%2Fweb-editing-wg-charter.html&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187704873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RmxqkOrUDQgu8CirPmk7wDKXAswir75DWOC7fEpX%2F98%3D&reserved=0>, >> it seems the chairs may be able to help move things along (e.g. by bringing >> decisions to a vote, if no consensus is reached). >> >> >> >> >> >> Anyways, I’m working on updating the spec to at least define the >> Clipboard interface IDL, but since Apple and Chromium browsers have already >> shipped this API, I don’t think it’s possible to make any significant >> changes to the APIs without breaking at least one of the browsers. >> >> This change addresses the discrepancy between the ClipboardItem IDL as >> defined in the spec(also implemented by Apple) and what is implemented in >> Chromium. This is not a breaking change so I think the risk is minimal here. >> >> >> >> *From:* Yoav Weiss <yoavwe...@chromium.org> >> *Sent:* Friday, October 1, 2021 4:15 AM >> *To:* Anne van Kesteren <ann...@annevk.nl> >> *Cc:* Anupam Snigdha <sni...@microsoft.com>; 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 >> >> >> >> >> >> >> >> On Fri, Oct 1, 2021 at 12:46 PM Anne van Kesteren <ann...@annevk.nl> >> wrote: >> >> On Fri, Oct 1, 2021 at 12:35 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> > Thanks Anne and Thomas for the cross-browser context. >> > >> > Anupam - looking at the issue Anne posted, it seems Firefox explicitly >> did not 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? >> >> There is an existing issue: >> https://github.com/mozilla/standards-positions/issues/89 >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F89&data=04%7C01%7Csnianu%40microsoft.com%7C7ed1d36fd6724750162508d989609436%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691870187704873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JHn9GNzlxbveQ94XVyAstVhxM2AGn5CvNTgT7Wg0Eyw%3D&reserved=0>. >> The problem >> we are having in evaluating all this is that there isn't really any >> specification to speak of, as I tried to point out. One can take >> guesses as to what the expected behavior is likely to be, but that is >> very far from ideal and normally not even close to acceptable, right? >> >> >> >> That's fair. >> >> >> >> From my perspective, the ideal outcome here would be: >> >> 1) Getting agreement on this specific issue that's currently causing >> developer pain, and moving forward in that direction. >> >> 2) Properly specifying the correct behavior for the rest of the broader >> API, in ways that would enable interoperable implementations (and reduce >> developer pain in the future). >> >> >> >> It seems like (2) requires Someone™ to take on the work of gathering the >> different unspecified behaviors, opening an issue to discuss each one, >> reaching agreement on them and pushing to align existing implementations. >> >> >> >> Maybe we can decouple (1) and (2), but I'd like to see we have a concrete >> plan for (2) before we do that. >> >> >> >> Anupam - who would be best positioned to take on that work? >> >> -- > 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/7a237c30-9d53-4181-9c5d-1954d2bf6a0cn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7a237c30-9d53-4181-9c5d-1954d2bf6a0cn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAABs73i6e64-hRNGEccw4PFpgnWFW1AQLi6HqBV3sTnPC-hNwA%40mail.gmail.com.
