LGTM3

On Thu, Aug 19, 2021 at 4:45 PM Alex Russell <[email protected]>
wrote:

> LGTM2, but I just want to make it clear that I don't think this is a
> strong precedent for weak cases for manifest extensions in future.
>
> The risk here isn't high, but neither is my confidence in the design. An
> OT for future designs like these, or a strong up-front case from developers
> for it, would help avoid delays.
>
> Regards
>
> On Thursday, August 19, 2021 at 12:33:48 PM UTC-7 Mike West wrote:
>
>> LGTM1.
>>
>> In general, I agree with Alex's suggestion that we should be gathering
>> developer feedback via OT, and particularly in cases where there's only
>> marginally web-exposed surface so that we get developers exercising the
>> embedder-level integration points to give y'all feedback on whether or not
>> those integration points meet their expectations.
>>
>> That said, I don't see much value in an OT for this particular API given
>> the way that its web-exposed surface is really all about spelling. I'm also
>> a little concerned that an OT would be non-trivial to implement, given the
>> fact that we'll be well outside of any particular document context at the
>> point when the integration would be executed. So, I think it's reasonable
>> to bypass in this particular case.
>>
>> -mike
>>
>>
>> On Mon, Aug 16, 2021 at 4:28 AM Glen Robertson <[email protected]>
>> wrote:
>>
>>> There have been some expressions of interest on the github issue
>>> <https://github.com/WICG/manifest-incubations/issues/25> (including
>>> some fairly sizable apps). There were also some suggestions to use a more
>>> generalised interface, but I'm still convinced by the arguments made in the
>>> explainer
>>> <https://github.com/WICG/manifest-incubations/blob/gh-pages/note_taking-explainer.md#alternatives-considered>
>>> (summarized from discussion with other web platform devs
>>> <https://github.com/w3c/manifest/issues/965>) that a specific,
>>> top-level field is appropriate. This is more along the lines of
>>> bike-shedding so I don't think an OT would help settle the discussion.
>>>
>>> Is this now sufficient developer interest to ship?
>>>
>>>
>>> On Fri, 13 Aug 2021 at 13:34, Glen Robertson <[email protected]>
>>> wrote:
>>>
>>>> Thanks Alex.
>>>> I'd prefer to ship instead of OT if reasonable, so I've asked a few
>>>> note-taking-web-app developers directly if they're interested and made a
>>>> github issue for them to post on
>>>> <https://github.com/WICG/manifest-incubations/issues/25> (I feel like
>>>> there wasn't an obvious avenue/CTA for them to publicly express support
>>>> before). I've also asked DevRel if they will point people at that link.
>>>>
>>>> I'll give that a few days and will fall back to an OT (in M94) if we
>>>> don't see sufficient interest expressed.
>>>>
>>>> On Fri, 13 Aug 2021 at 06:16, Alex Russell <[email protected]>
>>>> wrote:
>>>>
>>>>> hey Glen,
>>>>>
>>>>> We discussed again today in the OWNERs meeting and it seems like a
>>>>> good idea to get stronger developer signals here one way or another. I'm
>>>>> LGTM if you want to run an OT instead of shipping directly to do that, 
>>>>> else
>>>>> we can engage with our various developer relations teams to see if there's
>>>>> some way to drum up support for the design as-is.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> On Wednesday, August 11, 2021 at 12:23:39 AM UTC-7 Glen Robertson
>>>>> wrote:
>>>>>
>>>>>> Thanks for checking around MSFT, Alex.
>>>>>>
>>>>>> The reason we didn't go with an OT here was because the API seemed
>>>>>> small and uncontroversial and unlikely to change shape. We already had an
>>>>>> interested internal customer (plus there are many other note-taking web
>>>>>> apps out there, and existing users of the similar feature for note-taking
>>>>>> Chrome Apps). I didn't think it fit any of the bullet points under 
>>>>>> "Should
>>>>>> you run an origin trial?
>>>>>> <https://www.chromium.org/blink/origin-trials/running-an-origin-trial#TOC-Should-you-run-an-origin-trial->"
>>>>>> (perhaps the default assumption in that documentation should be flipped 
>>>>>> to
>>>>>> "you should run an OT unless in exceptional circumstances"?).
>>>>>>
>>>>>> If lack of interest is a problem we can disable the flag for M93 and
>>>>>> start an OT in M94 instead. Blink Leads, please let me know if that is
>>>>>> required.
>>>>>>
>>>>>> On Wed, 11 Aug 2021 at 04:51, Alex Russell <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> hey Glen,
>>>>>>>
>>>>>>> I've reached out to teams here at MSFT to see if there are other
>>>>>>> folks who need something similar, but don't have much to report.
>>>>>>>
>>>>>>> Given that this is a manifest change, it seems relatively low risk
>>>>>>> but the lack of developer interest is a red flag. Is there a reason this
>>>>>>> shouldn't go to OT first?
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>>
>>>>>>> On Monday, August 9, 2021 at 7:13:29 PM UTC-7 Glen Robertson wrote:
>>>>>>>
>>>>>>>> Is there any more needed from me here? M93 stable cut is coming up
>>>>>>>> in about 2 weeks and it would be nice to avoid delaying this to the 
>>>>>>>> next
>>>>>>>> release if possible.
>>>>>>>>
>>>>>>>> There are still no responses from Mozilla or Webkit on the
>>>>>>>> standards positions requests, but the DevRel tweet has positive 
>>>>>>>> responses
>>>>>>>> (38 likes and a positive reply).
>>>>>>>> TAG hasn't made any recommendations yet, beyond asking for
>>>>>>>> clarifications in the explainer (which I have done).
>>>>>>>>
>>>>>>>> On Mon, 2 Aug 2021 at 18:11, Glen Robertson <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> There was a generally positive reaction on the DevRel tweet about
>>>>>>>>> it <https://twitter.com/ChromiumDev/status/1417062059632644097>.
>>>>>>>>> We also have a 1P app that is already using it in beta internally 
>>>>>>>>> (internal
>>>>>>>>> CL <http://cl/380133411>).
>>>>>>>>> There was some platform developer discussion here
>>>>>>>>> <https://github.com/w3c/manifest/issues/965> that led us to the
>>>>>>>>> current design, but that was platform developers, not app developers.
>>>>>>>>>
>>>>>>>>> Is there some other avenue I can follow to get more feedback on
>>>>>>>>> the API?
>>>>>>>>>
>>>>>>>>> On Fri, 30 Jul 2021 at 05:22, Alex Russell <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> As discussed in today's OWNERS meeting, it would be helpful to
>>>>>>>>>> get developer signals. It's going to be hard to make a case that we 
>>>>>>>>>> should
>>>>>>>>>> ship this w/o some form of input from folks who need or want it.
>>>>>>>>>>
>>>>>>>>>> On Wednesday, July 28, 2021 at 7:44:09 AM UTC-7 Colin Blundell
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 28, 2021 at 2:14 AM Jason Robbins <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Sure.  I have a pull request in review for the additional
>>>>>>>>>>>> field-level help text:
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/GoogleChrome/chromium-dashboard/pull/1440/files
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> jason!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Looks great, thank you!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 22, 2021 at 5:55 AM Colin Blundell <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 22, 2021 at 9:15 AM Glen Robertson <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the clarification! In that case, the answer is
>>>>>>>>>>>>>> definitely "yes". crbug.com/1185678 is a good record of code
>>>>>>>>>>>>>> added to support the feature, though it relies on existing code 
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> supported note-taking Chrome Apps.
>>>>>>>>>>>>>> If possible, it would be nice to have a brief version of the
>>>>>>>>>>>>>> question's intent shown in the I2S template generated by 
>>>>>>>>>>>>>> Chromestatus!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the feedback! I assume that you mean something
>>>>>>>>>>>>> like: "Reply "yes" here if your feature has any implementation 
>>>>>>>>>>>>> code in
>>>>>>>>>>>>> //chrome, even if that's for functionality on top of the spec, so 
>>>>>>>>>>>>> that
>>>>>>>>>>>>> other //content embedders can be aware of that functionality." ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> +Jason Robbins <[email protected]>, would you be able to
>>>>>>>>>>>>> add this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Colin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 22 Jul 2021 at 00:57, Colin Blundell <
>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Glen,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Comment inline about the "requires code in //chrome?"
>>>>>>>>>>>>>>> question.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Jul 20, 2021 at 8:27 AM Glen Robertson <
>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for your replies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regarding signals: I've now requested positions from
>>>>>>>>>>>>>>>> Mozilla and Webkit, and asked for some help on the web 
>>>>>>>>>>>>>>>> developer front from
>>>>>>>>>>>>>>>> DevRel.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regarding web platform tests:
>>>>>>>>>>>>>>>> the spec'd behaviour
>>>>>>>>>>>>>>>> <https://wicg.github.io/manifest-incubations/index.html#new_note_url-member>
>>>>>>>>>>>>>>>> is intentionally that the user agent has no obligation to do 
>>>>>>>>>>>>>>>> anything with
>>>>>>>>>>>>>>>> the new field. It may use it in some way, or ignore it. The 
>>>>>>>>>>>>>>>> existing spec'd
>>>>>>>>>>>>>>>> behaviour of the web app manifest parser is that it must 
>>>>>>>>>>>>>>>> ignore unknown
>>>>>>>>>>>>>>>> fields[*]. Therefore, if we are testing compliance with the 
>>>>>>>>>>>>>>>> spec, I don't
>>>>>>>>>>>>>>>> think there is new behaviour to test here. If you think I 
>>>>>>>>>>>>>>>> should add a
>>>>>>>>>>>>>>>> note-taking-specific WPT test anyway I can.
>>>>>>>>>>>>>>>> *: I can't see a test for this, so I sent a CL
>>>>>>>>>>>>>>>> <http://crrev.com/c/3038042>. And another CL
>>>>>>>>>>>>>>>> <http://crrev.com/c/3038318> for adding a similar check in
>>>>>>>>>>>>>>>> manifest_parser_unittest, because manual WPT tests aren't very 
>>>>>>>>>>>>>>>> reassuring!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Re: "Requires code in //chrome? False" / OS integrations:
>>>>>>>>>>>>>>>> I wasn't quite sure about the intent of this question. The
>>>>>>>>>>>>>>>> spec doesn't require any code in chrome, and the field is 
>>>>>>>>>>>>>>>> parsed on all
>>>>>>>>>>>>>>>> platforms, but we do have code in //chrome to do an OS 
>>>>>>>>>>>>>>>> integration with it.
>>>>>>>>>>>>>>>> The OS integration is on Chrome OS only: it shows the app
>>>>>>>>>>>>>>>> in the list of note-taking apps in CrOS settings (already 
>>>>>>>>>>>>>>>> existed for
>>>>>>>>>>>>>>>> note-taking Chrome Apps, but only visible if you have a stylus
>>>>>>>>>>>>>>>> or --force-enable-stylus-tools) and, if selected by the user 
>>>>>>>>>>>>>>>> in that list,
>>>>>>>>>>>>>>>> the app can be launched from the stylus palette in the toolbar.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Good question! I just sent out information about this field.
>>>>>>>>>>>>>>> The intent is for feature developers to reply "yes" here if 
>>>>>>>>>>>>>>> their feature
>>>>>>>>>>>>>>> has implementation code in //chrome, even if that's for 
>>>>>>>>>>>>>>> functionality on
>>>>>>>>>>>>>>> top of the spec. The reason is that other //content embedders 
>>>>>>>>>>>>>>> might want to
>>>>>>>>>>>>>>> mirror that functionality.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Colin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What happens when 2+ webapps all define note taking
>>>>>>>>>>>>>>>> capabilities?
>>>>>>>>>>>>>>>> The spec doesn't define any required behaviour from the UA
>>>>>>>>>>>>>>>> upon detecting a note-taking app. It is similarly up to the UA 
>>>>>>>>>>>>>>>> what to do
>>>>>>>>>>>>>>>> with multiple note-taking apps. In CrOS the list of 
>>>>>>>>>>>>>>>> note-taking apps are
>>>>>>>>>>>>>>>> shown in stylus settings and the user may select one to be 
>>>>>>>>>>>>>>>> used with the
>>>>>>>>>>>>>>>> stylus palette.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is this capability feature detectable?
>>>>>>>>>>>>>>>> No. If it's not supported then note-taking web apps just
>>>>>>>>>>>>>>>> operate like any other web app.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'll wait on feedback from TAG and developer/vendor signals.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, 15 Jul 2021 at 19:16, Yoav Weiss <
>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thursday, July 15, 2021 at 11:08:38 AM UTC+2 Yoav Weiss
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thursday, July 15, 2021 at 10:34:35 AM UTC+2 Mike West
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Jul 13, 2021 at 5:08 AM Glen Robertson <
>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Contact emails [email protected],
>>>>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Explainer
>>>>>>>>>>>>>>>>>>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/note_taking-explainer.md
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Reading through the explainer I wonder:
>>>>>>>>>>>>>>>>> * What happens when 2+ webapps all define note taking
>>>>>>>>>>>>>>>>> capabilities? Which one wins? Or would the UA then present 
>>>>>>>>>>>>>>>>> the user with
>>>>>>>>>>>>>>>>> the choice, similar to native apps?
>>>>>>>>>>>>>>>>> * Is this capability feature detectable? Is there
>>>>>>>>>>>>>>>>> something developers can do when it's not supported? (I'm 
>>>>>>>>>>>>>>>>> guessing there's
>>>>>>>>>>>>>>>>> not much they can, but want to confirm)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Specification
>>>>>>>>>>>>>>>>>>>> https://wicg.github.io/manifest-incubations/index.html#note_taking-member
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> API spec Yes
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Summary
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Parses a web app manifest entry for a URL to open to
>>>>>>>>>>>>>>>>>>>> take a new note in a note-taking web app, allowing OS 
>>>>>>>>>>>>>>>>>>>> integrations.
>>>>>>>>>>>>>>>>>>>> Chrome for desktop release: M93
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Blink component Blink
>>>>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> TAG review
>>>>>>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/648
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The TAG seem engaged, so it's worthwhile to wait for their
>>>>>>>>>>>>>>>>> feedback.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> TAG review status Pending
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Risks
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Gecko*: No signal
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *WebKit*: No signal
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Web developers*: No signals
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please ask for signals, as per
>>>>>>>>>>>>>>>>>>> https://bit.li/blink-signals.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Similarly on the developer signals front, we have
>>>>>>>>>>>>>>>>>> goo.gle/developer-signals
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>>>>>>>>>>>>>>>>> ? Yes. No required behaviour.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm not sure I follow. It doesn't look like any web
>>>>>>>>>>>>>>>>>>> platform tests contain the string `note_taking`. Even if 
>>>>>>>>>>>>>>>>>>> there's no
>>>>>>>>>>>>>>>>>>> web-facing behavior this influences, it seems reasonable to 
>>>>>>>>>>>>>>>>>>> add it to a
>>>>>>>>>>>>>>>>>>> test that verifies its parsing.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Flag name blink::features::kWebAppNoteTaking
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Requires code in //chrome? False
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1185678,
>>>>>>>>>>>>>>>>>>> I see quite a bit of code that's landed in
>>>>>>>>>>>>>>>>>>> //chrome/browser/{chromeos,web_applications, etc}. It seems 
>>>>>>>>>>>>>>>>>>> like this
>>>>>>>>>>>>>>>>>>> feature depends upon the embedder doing some work to create 
>>>>>>>>>>>>>>>>>>> an integration
>>>>>>>>>>>>>>>>>>> with a platform-level (or UA-level, I suppose) note-taking 
>>>>>>>>>>>>>>>>>>> application?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Given that, are there platform restrictions on this
>>>>>>>>>>>>>>>>>>> feature? Or is this limited to a subset of the platforms 
>>>>>>>>>>>>>>>>>>> Blink supports?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Tracking bug
>>>>>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1185678
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Launch bug
>>>>>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1189357
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Measurement When a web app is launched to create a
>>>>>>>>>>>>>>>>>>>> note, a LaunchResult::WEB_APP_SUCCESS is recorded. See:
>>>>>>>>>>>>>>>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/chromeos/note_taking_helper.h;drc=d7a02514bb30afce607817fd2e8ef8a8af559739;l=130
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>>>>>>>>>> https://chromestatus.com/feature/5205972320518144
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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/ca5bf678-6d40-4b1e-bd38-0f9526ce408dn%40chromium.org
>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca5bf678-6d40-4b1e-bd38-0f9526ce408dn%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
>>>>>>>>>>>>>>>>> [email protected].
>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/078a3b24-bc49-42e4-b972-2a32e4d11025n%40chromium.org
>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/078a3b24-bc49-42e4-b972-2a32e4d11025n%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
>>>>>>>>>>>>>>>> [email protected].
>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_E3B8%3Du6xeN0Ub5MP3reAao7acqkEfEL8%2BhXW_yx0ZpA%40mail.gmail.com
>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_E3B8%3Du6xeN0Ub5MP3reAao7acqkEfEL8%2BhXW_yx0ZpA%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/CAMGE5NHhMmhWq%3DBj9_YrSeWD2uBX5Qr17mMp-ccFHEWOumnBOQ%40mail.gmail.com
>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGE5NHhMmhWq%3DBj9_YrSeWD2uBX5Qr17mMp-ccFHEWOumnBOQ%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/be979eff-62da-49ef-bf80-e2db81660fc0n%40chromium.org
>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/be979eff-62da-49ef-bf80-e2db81660fc0n%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 [email protected].
>>>>>>>
>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2dff1b47-3c46-4a8e-825e-10eff31b312dn%40chromium.org
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2dff1b47-3c46-4a8e-825e-10eff31b312dn%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 [email protected].
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2efcd4c8-d9a2-4590-82fc-61ed95fa995dn%40chromium.org
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2efcd4c8-d9a2-4590-82fc-61ed95fa995dn%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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67973b0f-a196-497a-8c59-9aac82571d40n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67973b0f-a196-497a-8c59-9aac82571d40n%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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-t%3D80CJvJ47QzmU7ZrYEX540h7pxKukym4MrQPzRUH%2BA%40mail.gmail.com.

Reply via email to