Hi Blink Owners, Have you had a chance to consider this yet? We are quickly approaching the end date of the current OT (2021-09-14).
On Fri, 27 Aug 2021 at 14:56, Glen Robertson <[email protected]> wrote: > Would it be possible for us to extend by 2 milestones to M95 (inclusive) > instead? We believe we can get a new v2 API (which will be a significant > breaking change) implemented in time for M96; M94 is already in beta and > M95 will not ship on CrOS, so the earliest we can get new code out to > developers is in M96 anyway. This would make our total OT timeline M88 to > M95 (8 milestones total), which is within the maximum OT time limit of 8 > milestones Alex mentioned above (in fact shorter total time due to the > changing milestone period). We would very much like to avoid the disruption > to developers of having the OT turned off and this functionality being > entirely unavailable during the intervening period before the new OT starts. > > We understand your concern about an extended OT risking burn-in, but this > is a complex API for developers to start using, as they have to create a > product and payment flow around it. Usage of the API is still low — a few > hundred calls per day total for all methods (excluding > getDigitalGoodsService, which is used for feature detection even when the > API is otherwise unavailable). > > Shipping a subset of the API now wouldn't help because we are proposing > breaking changes to enough of the API that it probably isn't useful to ship > the rest. Also, we are proposing a breaking change in the behaviour of the > feature detection function that must be called before any other calls, so > it would be mildly risky to ship that immediately. > > I have made a draft version of the proposed v2 API publicly available > <https://docs.google.com/document/d/16r8ZM_vTMNroB_JkoyKF9jdgiMNZXc2z7OfnsPYp8l4/edit#> > (though it is still being reviewed). It will be a significant breaking > change to the API. > > Thanks, > -Glen > > On Fri, 20 Aug 2021 at 06:33, Chris Harrelson <[email protected]> > wrote: > >> Hi, >> >> The API owners met to discuss this intent today (Chris, Yoav, Alex, >> Mike). We're glad to see you are still pursuing the API and responding to >> feedback with the v2 API. >> >> However, 9 milestones is very long, much longer than we are typically >> comfortable with, and within the range where there starts to be substantial >> risk of burn-in. That combined with the v2 design being neither publicly >> available nor implemented yet, leads us to conclude that we can't support >> extending the current Origin Trial, since there is also no >> defined experimental justification for doing so. >> >> You can of course come back and ask for a new Origin Trial once v2 is >> public and implemented. >> >> We also discussed two other points: >> * There is the option of shipping a subset now, but we were not sure if >> there is a useful and stable subset that could be shipped. >> * If v2 were implemented now and you wished to transition the Origin >> Trial "smoothly" to the new API, that would have been reasonable to >> consider. Reason being the purpose of an Origin Trial is to experimentally >> fit an API to purpose, and a change to v2 is a strong signal that there was >> experimental feedback justifying it. Further, a breaking v2 API would >> reduce burn-in risk. >> >> Thanks, >> Chris, on behalf of the API owners >> >> On Mon, Aug 16, 2021 at 2:17 AM Glen Robertson <[email protected]> >> wrote: >> >>> Hi Blink Owners, >>> >>> We would like to extend the DGAPI OT further. Requesting an extension to >>> M96 (inclusive). >>> >>> Note: that is 9 milestones total (8 on CrOS), some of which are the new >>> shorter milestones. Also CrOS won't ship M95. >>> >>> We now have an updated API design <http://go/dgapi2> in internal review >>> (sorry, Google only for now). I plan to update the public explainer once >>> the design is internally approved, then start on implementation of a >>> revised "v2" API. I expect implementation to take another milestone at >>> least, but like before we can't make promises about getting the engineering >>> part done within a tight timeline. When that is ready, we will want to >>> start an OT on that revised API. >>> >>> Also M94 (the existing post-end milestone) has already branched - do we >>> need to merge something to ensure DGAPI OT is not turned off for M94? >>> >>> Thanks >>> -Glen >>> >>> On Fri, 14 May 2021 at 10:19, Matt Giuca <[email protected]> wrote: >>> >>>> Thanks Alex and Yoav. >>>> >>>> On Fri, 14 May 2021 at 05:24, Alex Russell <[email protected]> >>>> wrote: >>>> >>>>> SGTM too; LGTM! >>>>> >>>>> On Monday, May 10, 2021 at 3:54:37 AM UTC-7 Yoav Weiss wrote: >>>>> >>>>>> On Mon, May 10, 2021 at 10:35 AM Matt Giuca <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks for the explanation, Yoav. >>>>>>> >>>>>>> Yes, we are talking about 6 milestones total (note: 5 milestones on >>>>>>> Chrome OS, which is where a lot of our customers are targeting, since we >>>>>>> missed the first milestone there). >>>>>>> >>>>>>> As said above, we are anticipating a V2 origin trial at some point >>>>>>> in the future. We think we'll have a pretty solid design by the end of >>>>>>> the >>>>>>> quarter (that's roughly corresponding to the start of M94) but we simply >>>>>>> can't promise that V2 will be implemented by then. When we get to M94, I >>>>>>> think it is likely that we'll need to further extend the existing origin >>>>>>> trial, but we should have a much better picture of the work required by >>>>>>> then. Another possibility is that we ship all or part of the current >>>>>>> API to >>>>>>> general availability (if it is determined that the new changes are >>>>>>> additions, rather than changes, to the existing API). >>>>>>> >>>>>> >>>>>> Ideally, at that point you would have well-documented learnings from >>>>>> the OT that you could use to justify either a decision to ship some parts >>>>>> of the API, or change it towards a second OT. >>>>>> >>>>>> >>>>>>> >>>>>>> Sorry if this is vague, but I am trying to keep our options open and >>>>>>> make sure that we aren't making promises we can't keep. My point above >>>>>>> stands, that I don't want to set hard engineering deadlines which, if we >>>>>>> don't meet them, will result in the disappearance of the API for our >>>>>>> customers. We are not trying to keep this API in origin trial forever, >>>>>>> but >>>>>>> we need time to work towards a solution. >>>>>>> >>>>>> >>>>>> The above SGTM! >>>>>> >>>>>> >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> On Mon, 10 May 2021 at 15:30, Yoav Weiss <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> In that case, we're talking about 6 milestones all in all? That >>>>>>>> sounds perfectly reasonable. >>>>>>>> >>>>>>>> On Mon, May 10, 2021 at 6:43 AM Glen Robertson < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Sorry, I made a mistake in my original email in this thread: we >>>>>>>>> actually delayed the start of the OT so I had the milestones wrong. >>>>>>>>> Corrected milestones follow: >>>>>>>>> >>>>>>>>> *Experimental timeline* >>>>>>>>> - M88(Android)/M89(Desktop): First experiment milestone >>>>>>>>> - M90: Original final experiment milestone >>>>>>>>> - M93: Extended final experiment milestone >>>>>>>>> >>>>>>>>> On Fri, 7 May 2021 at 23:19, Aer Berkopec <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, May 7, 2021, 3:44 AM Yoav Weiss <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hey Matt, >>>>>>>>>>> >>>>>>>>>>> The main goals for the duration restrictions that Alex mentioned >>>>>>>>>>> is to avoid cases where Origin Trials are being used as a "soft >>>>>>>>>>> launch" >>>>>>>>>>> mechanism and to avoid prematurely baking in the feature into the >>>>>>>>>>> platform. >>>>>>>>>>> Significant changes to the API shape (as the ones you allude to >>>>>>>>>>> with the V2 API) would provide some assurances against bake in, and >>>>>>>>>>> from my >>>>>>>>>>> perspective would "restart the clock". >>>>>>>>>>> >>>>>>>>>>> However, that doesn't mean that breaking the API every X >>>>>>>>>>> milestones would enable y'all to have it in OT forevermore. We also >>>>>>>>>>> want to >>>>>>>>>>> see that the OT is being used to provide us with meaningful >>>>>>>>>>> feedback. I >>>>>>>>>>> believe that's the reason Alex asked for a summary of lessons >>>>>>>>>>> learned, as >>>>>>>>>>> well as a plan to eventually ship this. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, May 7, 2021 at 9:37 AM Matt Giuca <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Alex, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the notes from your meeting. I think we can create a >>>>>>>>>>>> summary of the proposed design changes (however, note that it's >>>>>>>>>>>> somewhat >>>>>>>>>>>> undecided at this stage, what specific changes will need to be >>>>>>>>>>>> made). I >>>>>>>>>>>> don't want to block the extension of the origin trial on having a >>>>>>>>>>>> design >>>>>>>>>>>> proposal, since that could jeopardize customers' ability to use >>>>>>>>>>>> the API. >>>>>>>>>>>> >>>>>>>>>>>> Does the 8-milestone run include the planned future "V2 API" >>>>>>>>>>>> origin trial, (i.e. if we run this for another 3 milestones, we'll >>>>>>>>>>>> only >>>>>>>>>>>> have 2 milestones left to do a V2 origin trial)? Or do you mean 8 >>>>>>>>>>>> milestones without making changes to the API. >>>>>>>>>>>> >>>>>>>>>>>> I think the latter would be pretty reasonable, but as I'm sure >>>>>>>>>>>> I've said before, I'm not too comfortable having a hard deadline >>>>>>>>>>>> on having >>>>>>>>>>>> to ship a new API or losing it. Having hard deadlines for shipping >>>>>>>>>>>> features, especially one this complex, generally results in rushed >>>>>>>>>>>> and >>>>>>>>>>>> buggy experiences. If we, say, get to M95 and have a working >>>>>>>>>>>> implementation >>>>>>>>>>>> for V2, but discover a bug at the last minute, I want to be able >>>>>>>>>>>> to have no >>>>>>>>>>>> hesitation to punt the release for an additional milestone (I >>>>>>>>>>>> don't want us >>>>>>>>>>>> to feel compelled to push it out the door because of an arbitrary >>>>>>>>>>>> 8-milestone limit). >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We definitely don't want you or other feature teams to rush to >>>>>>>>>>> ship features that are not ready. What I'd generally recommend is >>>>>>>>>>> for you >>>>>>>>>>> to have a rough plan for exiting the experimentation phase, and to >>>>>>>>>>> come >>>>>>>>>>> back to the API owners if e.g. last minute extensions are needed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'll note that I raised this issue for this specific API in a >>>>>>>>>>>> general discussion with Blink API Owners in November 2020 ( >>>>>>>>>>>> email >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/_VsWsXMlezY/m/jTjGda60CwAJ>). >>>>>>>>>>>> Relevant quotes from myself from that email: >>>>>>>>>>>> >>>>>>>>>>>> Until this work is done, we're not comfortable shipping this >>>>>>>>>>>>> API. We think backwards-incompatible changes may be required. But >>>>>>>>>>>>> we want >>>>>>>>>>>>> to get it into the hands of developers before then. An origin >>>>>>>>>>>>> trial lets us >>>>>>>>>>>>> do that, but it's got a soft time limit (3 milestones), after >>>>>>>>>>>>> which time >>>>>>>>>>>>> we'll have to apply for an extension. Maybe that's fine, because >>>>>>>>>>>>> we have >>>>>>>>>>>>> specific questions we'll still want answered. But it seems a >>>>>>>>>>>>> little unfit >>>>>>>>>>>>> for purpose, because we aren't using the OT to answer those >>>>>>>>>>>>> questions, >>>>>>>>>>>>> we're just extending it to keep things working while we do design >>>>>>>>>>>>> work >>>>>>>>>>>>> behind the scenes. >>>>>>>>>>>>> ... >>>>>>>>>>>>> If API owners are happy with us ... repeatedly extending the >>>>>>>>>>>>> origin trial, without specific experimental questions, until we >>>>>>>>>>>>> have done >>>>>>>>>>>>> the internal research / spec work required to ship, then I think >>>>>>>>>>>>> we can do >>>>>>>>>>>>> without origin keys. My proposal was essentially an attempt to >>>>>>>>>>>>> formalize >>>>>>>>>>>>> that behaviour, rather than having to apply for all of these >>>>>>>>>>>>> exemptions and >>>>>>>>>>>>> extensions when they come up. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now I didn't get a response to that email at the time. The >>>>>>>>>>>> context was that we were asking for a formal "origin keys >>>>>>>>>>>> <https://docs.google.com/document/d/1rQFoxVEOHBAYGz0DL0eSUur-DWN90o42OzFtEmcAO-Q/edit>" >>>>>>>>>>>> system, and in that meeting, I was told that it wouldn't be >>>>>>>>>>>> necessary >>>>>>>>>>>> because origin trials are suitable for that purpose. Per my final >>>>>>>>>>>> paragraph >>>>>>>>>>>> there, it *may* not be that origin trials are suitable for >>>>>>>>>>>> this purpose, if in practice API owners are going to block origin >>>>>>>>>>>> trial >>>>>>>>>>>> extensions. >>>>>>>>>>>> >>>>>>>>>>>> To be clear, we aren't intending to extend this indefinitely. I >>>>>>>>>>>> am hoping we can have this API shipped some time this year. But I >>>>>>>>>>>> am >>>>>>>>>>>> flagging that we can't guarantee that we'll have the necessary >>>>>>>>>>>> changes made >>>>>>>>>>>> by a specific milestone, and I don't want to be hard-bound to make >>>>>>>>>>>> those >>>>>>>>>>>> changes by a specific date. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, 7 May 2021 at 05:34, Alex Russell < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hey all, >>>>>>>>>>>>> >>>>>>>>>>>>> Met today at API OWNERS to discuss. I don't think folks are >>>>>>>>>>>>> *necessarily* opposed to extending this, but a few things >>>>>>>>>>>>> jump out: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - 8 milestones as at the far end of how long we'd like any >>>>>>>>>>>>> OT to run >>>>>>>>>>>>> - Given that, it would be helpful to summarize both a plan >>>>>>>>>>>>> for what the new API will look like as well as lessons learned >>>>>>>>>>>>> to date >>>>>>>>>>>>> >>>>>>>>>>>>> I know that some of that is captured in the DGAPI bugs linked, >>>>>>>>>>>>> but it would help if there were a summary document that described >>>>>>>>>>>>> the >>>>>>>>>>>>> developer feedback to date, the changes you'll be making to the >>>>>>>>>>>>> API to >>>>>>>>>>>>> compensate, and the plan for (hopefully) validating the new API >>>>>>>>>>>>> works as >>>>>>>>>>>>> developers expect quickly, then launching or sunsetting. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, May 6, 2021 at 8:30:38 AM UTC-7 Glen Robertson >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>> >>>>>>>>>>>>>> [email protected], [email protected], >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/WICG/digital-goods/blob/master/explainer.md >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specification >>>>>>>>>>>>>> >>>>>>>>>>>>>> None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Design docs >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/WICG/digital-goods/blob/master/explainer.md >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit >>>>>>>>>>>>>> >>>>>>>>>>>>>> Summary >>>>>>>>>>>>>> >>>>>>>>>>>>>> An API for querying and managing digital products to >>>>>>>>>>>>>> facilitate in-app purchases from web applications, in >>>>>>>>>>>>>> conjunction with the >>>>>>>>>>>>>> Payment Request API (which is used to make the actual >>>>>>>>>>>>>> purchases). The API >>>>>>>>>>>>>> would be linked to a digital distribution service connected to >>>>>>>>>>>>>> via the user >>>>>>>>>>>>>> agent. In Chromium, this is specifically a web API wrapper >>>>>>>>>>>>>> around the >>>>>>>>>>>>>> Android Play Billing API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>> >>>>>>>>>>>>>> Blink>Payments >>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Search tags >>>>>>>>>>>>>> >>>>>>>>>>>>>> payments <https://chromestatus.com/features#tags:payments>, >>>>>>>>>>>>>> billing <https://chromestatus.com/features#tags:billing> >>>>>>>>>>>>>> >>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/571 >>>>>>>>>>>>>> >>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>> >>>>>>>>>>>>>> In progress >>>>>>>>>>>>>> >>>>>>>>>>>>>> RisksInteroperability and Compatibility >>>>>>>>>>>>>> >>>>>>>>>>>>>> Similar to Payment Request: this API is used to talk to >>>>>>>>>>>>>> specific store backends, and so its usage is tailored to the >>>>>>>>>>>>>> specific >>>>>>>>>>>>>> store. The reason it's a proposed web standard is so that the >>>>>>>>>>>>>> same code >>>>>>>>>>>>>> (which is specific to one store) is portable across browsers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gecko: No signal ( >>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/349). >>>>>>>>>>>>>> Awaiting feedback. >>>>>>>>>>>>>> >>>>>>>>>>>>>> WebKit: No signal >>>>>>>>>>>>>> >>>>>>>>>>>>>> Web developers: Positive ( >>>>>>>>>>>>>> https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350 >>>>>>>>>>>>>> ) >>>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>>> >>>>>>>>>>>>>> Used in tandem with the Payment Request API. >>>>>>>>>>>>>> Goals for experimentation >>>>>>>>>>>>>> >>>>>>>>>>>>>> - General API design. Determine whether developers need to >>>>>>>>>>>>>> access more data that would be exposed through the Play Billing >>>>>>>>>>>>>> API but is >>>>>>>>>>>>>> not exposed through our web API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Specifically, we would like to know whether the API is >>>>>>>>>>>>>> suitable for abstracting over other non-Play stores. While >>>>>>>>>>>>>> running an >>>>>>>>>>>>>> experiment with the current implementation won't tell us this, >>>>>>>>>>>>>> it will set >>>>>>>>>>>>>> up real-world clients and we can then try their sites on other >>>>>>>>>>>>>> implementations. >>>>>>>>>>>>>> Experimental timeline >>>>>>>>>>>>>> >>>>>>>>>>>>>> - M87 (2020-11-17): Experiment begins >>>>>>>>>>>>>> >>>>>>>>>>>>>> - M90 (2021-04-13): Original experiment end date >>>>>>>>>>>>>> >>>>>>>>>>>>>> - M93 (2021-08-31): Extended experiment end date >>>>>>>>>>>>>> >>>>>>>>>>>>>> Reason this experiment is being extended >>>>>>>>>>>>>> >>>>>>>>>>>>>> An origin trial ran from M87 to M90 and found some areas of >>>>>>>>>>>>>> developer friction and new features needed (see bugs labeled >>>>>>>>>>>>>> DGAPI >>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=label%3ADGAPI>). >>>>>>>>>>>>>> We haven't yet had time to fix all the issues and update the >>>>>>>>>>>>>> API. We are >>>>>>>>>>>>>> planning to update the API and run a next phase of the >>>>>>>>>>>>>> experiment with a v2 >>>>>>>>>>>>>> API soon. We would like to avoid stopping the experiment in >>>>>>>>>>>>>> between the >>>>>>>>>>>>>> phases to avoid unnecessarily disrupting current users of the >>>>>>>>>>>>>> API while we >>>>>>>>>>>>>> work on the next iteration. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ongoing technical constraints >>>>>>>>>>>>>> >>>>>>>>>>>>>> None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> No, Android and Chrome OS only (the two platforms where we >>>>>>>>>>>>>> have Play Store integration). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>> ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> No >>>>>>>>>>>>>> >>>>>>>>>>>>>> Flag name >>>>>>>>>>>>>> >>>>>>>>>>>>>> None >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://crbug.com/1061503 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Launch bug >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://crbug.com/1017947 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://chromestatus.com/feature/5339955595313152 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>>> >>>>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs >>>>>>>>>>>>>> >>>>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ >>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>> <https://www.chromestatus.com/>. >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcYbiwZYA6atQ%3DsN6nkaT6M-7avGhOBdwjA373PG%3DCq2cg%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcYbiwZYA6atQ%3DsN6nkaT6M-7avGhOBdwjA373PG%3DCq2cg%40mail.gmail.com?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 [email protected]. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW657p0WOQSZeJtJdNz%2Bo5EYdy8q7uJDfb%3D05MUXtLLSg%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW657p0WOQSZeJtJdNz%2Bo5EYdy8q7uJDfb%3D05MUXtLLSg%40mail.gmail.com?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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_pU3Q59ZcBVDyY-TFDmhUjW_3e6wqPRfWLZDqJER_r4Q%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_pU3Q59ZcBVDyY-TFDmhUjW_3e6wqPRfWLZDqJER_r4Q%40mail.gmail.com?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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg9Kyca3JTU9ZoqsCsEMr4Uuojq8cXge8W4eokF9qZ1CCQ%40mail.gmail.com.
