On Fri, Oct 29, 2021 at 3:56 AM Anupam Snigdha <sni...@microsoft.com> wrote:
> Let me try to clarify few things. Currently there is *no *user activation > requirements in async clipboard read/write in Chromium browsers. e.g. > https://clumsy-garnet-meeting.glitch.me/. Just load this page and refresh > it without clicking anywhere on the page, you will see the content will get > written to the clipboard without any gesture. > Writing to the clipboard is quite distinct from reading from the clipboard, isn't it? https://gifted-stingy-ketchup.glitch.me/ actually surfaces a permission prompt when executing `navigator.clipboard.read()`, which is more in line with my expectations. > Safari, due to security concerns, implemented a gesture requirement to > access clipboard via async clipboard APIs. The read()/write() method can > only be called inside a trusted user gesture event handler, but the > promises to Blobs can be resolved later which gives the web authors the > flexibility to not block the thread to populate the payload. > The question in my mind relates to the content of that promise's resolution. Is the resulting blob created at the point at which the `read()` method is called (as a "copy of the system clipboard data")? Or is the resolution "active" in some sense, returning a blob representing whatever happens to be in the clipboard at the time the promise is resolved? > In Pickling API > <https://github.com/w3c/editing/blob/gh-pages/docs/clipboard-pickling/explainer.md>, > which adds capability to the async clipboard API to read/write unsanitized > content, initially we added a transient user activation requirement because > the API lets web authors read/write unsanitized content using a custom > clipboard format. Both Chrome security team(see "User Gesture Requirement" > section in https://github.com/w3c/editing/issues/315) and TAG( > https://github.com/w3ctag/design-reviews/issues/636#issuecomment-857829725) > raised the concern that transient user activation is NOT sufficient to give > clipboard access to web authors. > That sounds right to me, and points again to the question above: does a click give you access to the clipboard _now_, or at some arbitrary point in the future? This change is required to not only support the Pickling API's user gesture > event handling requirements, but also improve the security by adding an > even stronger signal of the user intent to copy. We also talked about this > in the Editing WG call with Apple and they are opposed to transient user > activation and I believe Firefox raised concerns as well( > https://github.com/w3c/clipboard-apis/issues/52#issuecomment-599443986). > > Re: clipboard spec: I believe the spec needs to be updated so I've started > this PR: https://github.com/w3c/clipboard-apis/pull/158. > > Please let me know if you have any other quesions/concerns. > > -Anupam > > > > ------------------------------ > *From:* Mike West <mk...@chromium.org> > *Sent:* Thursday, October 28, 2021 12:17 PM > *To:* Anupam Snigdha <sni...@microsoft.com> > *Cc:* bratel...@gmail.com <bratel...@gmail.com>; dome...@chromium.org < > dome...@chromium.org>; yoavwe...@chromium.org <yoavwe...@chromium.org>; > blink-dev@chromium.org <blink-dev@chromium.org>; ann...@annevk.nl < > ann...@annevk.nl>; m...@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 > > We discussed this in the API owners' meeting, and there's some confusion > both about what's specified, and what Chromium's implementation does. I > read https://github.com/w3c/clipboard-apis/issues/161 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fissues%2F161&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072866700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hqbLhbCrhnx0mMTXsmy2aCei9RLpIbI8KI0GhMN5ieM%3D&reserved=0> > as suggesting that the `ClipboardItem` has a promise which, when resolved, > provides access to the current contents of the clipboard (and a response > suggests that there's a 1 second limit on that). Step 2.3 of > https://www.w3.org/TR/clipboard-apis/#dom-clipboard-read > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fclipboard-apis%2F%23dom-clipboard-read&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072876690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NWaqKZBi58NVVKpJGOu9PfLPE32VAmBg%2BMtnqy8mRVY%3D&reserved=0> > suggests that read operations return "a copy of the system clipboard data", > which seems inconsistent. > > Can y'all help me understand what our model is here? And what the model > ought to be, if it diverges from what we've currently implemented? > > -mike > > > On Wed, Oct 27, 2021 at 8:07 PM 'Anupam Snigdha' via blink-dev < > blink-dev@chromium.org> wrote: > > Thanks Daniel for raising this concern. I have opened an issue to discuss > with the Editing WG: https://github.com/w3c/clipboard-apis/issues/161 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fissues%2F161&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072886694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XhNKvRseB3%2F5rebvOGwZYBgHGCaG2oysNsz28%2BlOQeg%3D&reserved=0>. > In the current implementation, I think verifying whether the Document is > active or not after the promises have been resolved should mitigate some of > the concerns. > > > > *From:* Daniel Bratell <bratel...@gmail.com> > *Sent:* Thursday, October 21, 2021 12:48 PM > *To:* Domenic Denicola <dome...@chromium.org>; Yoav Weiss < > yoavwe...@chromium.org> > *Cc:* blink-dev <blink-dev@chromium.org>; Anupam Snigdha < > sni...@microsoft.com>; ann...@annevk.nl <ann...@annevk.nl>; 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 > > > > Inspired by the recent talk about user interaction, I feel like there is > one thing I want to understand. > > So with a Promise you move the execution to a later time. Is it possible > here for a malicious page to delay an action to much, much later and then > do that clipboard operation on data that was not available at the time of > the clipboard operation the user initiated? > > If so, could that have security implications? > > Could there even be more than one ongoing clipboard operation at a time? > > /Daniel > > > > On 2021-10-21 17:20, Domenic Denicola wrote: > > > > > > On Thu, Oct 21, 2021 at 5:21 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > > LGTM1 to ship conditional that y'all continue to work on PR #158 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fclipboard-apis%2Fpull%2F158&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072896682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5uP05FPMvfAuCp1SUI%2FLg%2B4TXQ1W7gTJNEmyqsCgV0E%3D&reserved=0> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.chromium.org%2Fchromium%2Fchromium%2Fsrc%2F%2B%2Fmain%3Athird_party%2Fblink%2Frenderer%2Fbindings%2Fcore%2Fv8%2Fnative_value_traits_impl.h%3Bl%3D775%3Fq%3DArgumentValue%26ss%3Dchromium%252Fchromium%252Fsrc&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072896682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FTudEC79sUrcFDkGRhYnFuPS855YOzlYk9f2qOUnTh4%3D&reserved=0>` > on that value, which casts > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.chromium.org%2Fchromium%2Fchromium%2Fsrc%2F%2B%2Fmain%3Athird_party%2Fblink%2Frenderer%2Fbindings%2Fcore%2Fv8%2Fscript_promise.cc%3Bdrc%3Dac35167cc1cf9c40778c1e1d8855fd90a90f0fbf%3Bl%3D291&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072906686%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2KRkVVGfb0KWzcxHsgjjpGBhTUJbcg%2FQppN9q%2BJDrIU%3D&reserved=0> > 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? > > > > It is: https://webidl.spec.whatwg.org/#es-promise > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebidl.spec.whatwg.org%2F%23es-promise&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072916670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FASK8Hh4nPqwoCN5CMgYP%2Febf1ZZKmJmHxE2uYdAcm8%3D&reserved=0> > > > > > > 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%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072926665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=D%2BWGf9HzbkLaU0ZaptNV43LPG68cVNx01nrcjX%2FlcQk%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%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072936659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uMeeRXk4ziGdXUj0q8dOiCvHYqmfYv0%2FYawgvyKTPWU%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%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072936659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wM8RZVhTzE%2F0Yqygd0dPn9XemClTVUiICIdP0KLO1wU%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%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072946657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YvHUMsv%2FB8TmFQ8t0dcx4EtGCtOJxgcFt%2FaYpN4ZZWc%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%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072956651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JleHJji%2BQTN1agkrOqnZwgpchu%2FCniNWgXlq9cyzP5I%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%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072966643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bTEVl5L%2Bjo50sgWy7yHl40%2FY8JGFOv5ATAik4iM0sJQ%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%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072966643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MkOrbwlo6eC%2BI%2Fo9v9QOZK4dScnsWBAGWP30BXG10qA%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2F7a237c30-9d53-4181-9c5d-1954d2bf6a0cn%2540chromium.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072976637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=beRl9PFJNRa57iMF8mgIZlm5Env7Cv7pcNvq8blsMQQ%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/CAM0wra-e-Y3%3DSn_LQ7qCLKahrg8WaOfoi4LR1TGMN4%3D5-Dn7kQ%40mail.gmail.com > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FCAM0wra-e-Y3%253DSn_LQ7qCLKahrg8WaOfoi4LR1TGMN4%253D5-Dn7kQ%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072986632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bY7S97piaZDNGGZTjsr5LU1uTOpBHzNGJUtZWlClndI%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/SN6PR00MB03977ABE1FD1C66C98131F60CF859%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%2FSN6PR00MB03977ABE1FD1C66C98131F60CF859%2540SN6PR00MB0397.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Csnianu%40microsoft.com%7C0a495f1387824571e3e408d99a47afbc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710455072996625%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LW070iidkb3GLDmAUTCLNSOkZLznOhQRodsGYs7u520%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/CAKXHy%3DciaMNUB64Gc6Z%2Bqrp07Dfy8VPVrN0LLS-Js4%3DNQQDpOA%40mail.gmail.com.
