Thanks! I just submitted the creation request.
On Tue, Jun 4, 2024 at 7:34 AM Jason Robbins <jrobb...@google.com> wrote: > OK, I think that I found the problem and fixed it in ChromeStatus > database. I reran the cron job that previously overwrote my simpler fix > and it did not overwrite my more-complete fix. So, you should now see the > "Request Trial Creation" button on the V3 OT stage, and it should still be > there until you press it and submit the form. > > Thanks, > jason! > On Monday, June 3, 2024 at 12:01:10 PM UTC-7 Jason Robbins wrote: > >> Hmm, after I cleared out the wrong data, something filled it in again. I >> will try to track down that ChromeStatus bug today. >> >> Thanks, >> jason! >> >> On Sunday, June 2, 2024 at 4:59:33 PM UTC-7 Tsuyoshi Horo wrote: >> >>> Hi. >>> >>> On Sat, Jun 1, 2024 at 3:04 AM Jason Robbins <jrob...@google.com> wrote: >>> >>>> Tsuyoshi, >>>> >>>> Previously your third OT stage on ChromeStatus got associated with your >>>> second trial on OT Console. That is probably due to a bug in ChromeStatus. >>>> We'll look into that. >>>> >>>> To let you continue with requesting this new trial, I have cleared out >>>> the trial ID for that third OT stage on ChromeStatus. Now you should see a >>>> "Request Trial Creation" button on that stage that looks like: >>>> https://screenshot.googleplex.com/4RZcpmCHJgxSnaT >>>> >>> >>> Sorry, I can't find the "Request Trial Creation" button. >>> I still see the "Request a trial extension" button, not the "Request >>> Trial Creation". >>> https://screenshot.googleplex.com/9PNnFQLkQBTVwdU >>> And the "View Origin Trial" button is linked to the previous V2 Origin >>> trial console URL >>> <https://developer.chrome.com/origintrials/#/view_trial/3693514644397228033> >>> . >>> >>> >>> >>> >>>> >>>> >>>> You will need to change some fields in the form to indicate that this >>>> is for your "V3" trial. >>>> Please note that each distinct trial requires a distinct trial name >>>> with an entry in >>>> >>>> https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/runtime_enabled_features.json5 >>>> The "Request Trial Creation" form handler now checks that file when you >>>> submit, so you may need to land a change to that file before you can >>>> successfully submit the form. >>>> >>>> Thanks, >>>> jason! >>>> >>>> >>>> >>>> >>>> On Friday, May 31, 2024 at 6:24:37 AM UTC-7 mike...@chromium.org wrote: >>>> >>>>> Thanks Domenic - I agree. >>>>> On 5/30/24 9:31 PM, Domenic Denicola wrote: >>>>> >>>>> LGTM for a new OT from 127 to 129. >>>>> >>>>> (Speaking generally, I think starting new OTs is better than extending >>>>> existing ones, so I am glad the team has taken this route. From an >>>>> ecosystem perspective, new OTs make it easier for the team to make >>>>> breaking >>>>> changes, and encourages OT participants to continually re-engage with the >>>>> process.) >>>>> >>>>> On Friday, May 31, 2024 at 10:07:00 AM UTC+9 jrob...@google.com wrote: >>>>> >>>>>> Mike or other API Owners, still approved given that this is actually >>>>>> requesting a new OT? >>>>>> >>>>>> Thanks, >>>>>> jason! >>>>>> >>>>>> On Wednesday, May 29, 2024 at 5:10:54 PM UTC-7 Tsuyoshi Horo wrote: >>>>>> >>>>>>> Ah, sorry for the confusion. >>>>>>> >>>>>>> This request is for the V3 Origin Trial. >>>>>>> >>>>>>> V1 OT was from 117 to 122. >>>>>>> V2 OT was from 122 to 125. >>>>>>> And this V3 OT is from 127 to 129. >>>>>>> >>>>>>> >>>>>>> On Thu, May 30, 2024 at 8:32 AM Patrick Meenan <pme...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>> Sorry, probably some confusion with the process. >>>>>>>> >>>>>>>> This is for the 3rd round of OT on the platform status entry >>>>>>>> (CompressionDictionaryTransportV3) so "extend" may not be the right >>>>>>>> terminology. V1 really ended at 122 and we had the same confusion the >>>>>>>> last >>>>>>>> time around and the V2 trial was created that went from 123-125 (and >>>>>>>> is the >>>>>>>> current active trial). >>>>>>>> >>>>>>>> I'll leave it to Tsuyoshi so I don't accidentally break anything, >>>>>>>> but I assume we need to mark the v3 trial as the active stage. >>>>>>>> >>>>>>>> On Wed, May 29, 2024 at 7:16 PM Panos Astithas <past...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>> Hi Tsuyoshi, >>>>>>>>> >>>>>>>>> Is this a request to extend the V1 OT as it appears in >>>>>>>>> Chromestatus and in the title of this thread or are you trying to >>>>>>>>> create a >>>>>>>>> new V3 trial as it seems to be the intent based on the content of your >>>>>>>>> intent? Note that V1 ended at M125, so teh extension would be for 4 >>>>>>>>> milestones. >>>>>>>>> >>>>>>>>> On Wed, May 29, 2024 at 10:22 AM Mike Taylor <mike...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>> Thanks all. LGTM to extend from 127 to 129 inclusive. >>>>>>>>>> On 5/29/24 10:51 AM, Patrick Meenan wrote: >>>>>>>>>> >>>>>>>>> On the spec side of things, there is one more issue outstanding in >>>>>>>>>> the IETF discussion but it's not API-impacting and we expect that >>>>>>>>>> this latest >>>>>>>>>> draft >>>>>>>>>> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/04/>, >>>>>>>>>> which this OT implements, has the final API shape. There will be some >>>>>>>>>> tweaks around the edges as we go through the final steps of the RFC >>>>>>>>>> process >>>>>>>>>> but the V3 OT will give sites something to test against that matches >>>>>>>>>> what >>>>>>>>>> we expect to ship. >>>>>>>>>> >>>>>>>>>> There are some fairly substantial changes from the previous OT >>>>>>>>>> that it would be useful to get feedback on. In particular, the >>>>>>>>>> change to >>>>>>>>>> the file format that embeds the dictionary hash into the file itself >>>>>>>>>> instead of being a separate response header. >>>>>>>>>> >>>>>>>>>> On Wed, May 29, 2024 at 10:37 AM Yoav Weiss (@Shopify) < >>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, May 29, 2024 at 4:31 PM Mike Taylor < >>>>>>>>>>> mike...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi there, >>>>>>>>>>>> >>>>>>>>>>>> Would you mind commenting on progress for the following items, >>>>>>>>>>>> per OT renewal guidelines: >>>>>>>>>>>> >>>>>>>>>>> <API owner hat off / feature champion hat on> >>>>>>>>>>> >>>>>>>>>>>> Draft spec (early draft is ok, but must be spec-like and >>>>>>>>>>>> associated with the appropriate standardization venue, or WICG) >>>>>>>>>>>> >>>>>>>>>>> Recently published >>>>>>>>>>> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/> >>>>>>>>>>> with >>>>>>>>>>> above-mentioned changes. >>>>>>>>>>> +Patrick Meenan can probably add precision there, but it's >>>>>>>>>>> making good progress in the HTTPWG. >>>>>>>>>>> >>>>>>>>>>> TAG review (see exceptions) >>>>>>>>>>>> >>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/877 >>>>>>>>>>> >>>>>>>>>>>> bit.ly/blink-signals requests >>>>>>>>>>>> >>>>>>>>>>> Both Mozilla >>>>>>>>>>> <https://github.com/mozilla/standards-positions/issues/771> and >>>>>>>>>>> WebKit >>>>>>>>>>> <https://github.com/WebKit/standards-positions/issues/160> are >>>>>>>>>>> positive (with ongoing discussion about some details with Mozilla >>>>>>>>>>> folks). >>>>>>>>>>> >>>>>>>>>>>> Outreach for feedback from the spec community >>>>>>>>>>>> >>>>>>>>>>> Regular HTTPWG and WebPerfWG engagement. >>>>>>>>>>> >>>>>>>>>>>> WPT tests >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://wpt.fyi/results/fetch/compression-dictionary?label=experimental&label=master&aligned >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>>>> Mike >>>>>>>>>>>> On 5/28/24 5:59 AM, Tsuyoshi Horo wrote: >>>>>>>>>>>> >>>>>>>>>>> Contact emails >>>>>>>>>>>> >>>>>>>>>>>> ho...@chromium.org, pme...@chromium.org, yoav...@chromium.org, >>>>>>>>>>>> kenji...@chromium.org, deno...@chromium.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Explainer >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/WICG/compression-dictionary-transport >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Specification >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Design docs >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/WICG/compression-dictionary-transport >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Summary >>>>>>>>>>>> >>>>>>>>>>>> We are running the second round of the Origin Trial until >>>>>>>>>>>> Chrome 125. The design of the feature has also evolved during the >>>>>>>>>>>> origin >>>>>>>>>>>> trial and RFC process. We’d like to run a third round of the >>>>>>>>>>>> Origin Trial >>>>>>>>>>>> to get more feedback on the updated >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/d934bf37456735d9bc03107c577804f439f8a986/docs/experiments/compression-dictionary-transport.md#changes-in-m127> >>>>>>>>>>>> design. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Blink component >>>>>>>>>>>> >>>>>>>>>>>> Blink>Network >>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> TAG review >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/877 >>>>>>>>>>>> TAG review status >>>>>>>>>>>> >>>>>>>>>>>> Closed >>>>>>>>>>>> Risks Interoperability and Compatibility >>>>>>>>>>>> >>>>>>>>>>>> Interoperability and Compatibility risk are low. This feature >>>>>>>>>>>> introduces a new compression method for transporting resources >>>>>>>>>>>> over HTTP. >>>>>>>>>>>> Web sites can know the browser support for the new feature by >>>>>>>>>>>> checking >>>>>>>>>>>> `document.createElement('link').relList.supports('compression-dictionary')`. >>>>>>>>>>>> The feature is a negotiation between servers and clients that >>>>>>>>>>>> involves a >>>>>>>>>>>> server specifying that a resource should be used as a dictionary >>>>>>>>>>>> for future >>>>>>>>>>>> requests with a ‘Use-As-Dictionary’ response header. Clients that >>>>>>>>>>>> don’t >>>>>>>>>>>> support the feature will ignore the header and nothing further >>>>>>>>>>>> will happen. >>>>>>>>>>>> >>>>>>>>>>>> This feature is an opt-in feature. And the dictionary storage >>>>>>>>>>>> is isolated using the top level site and the frame origin as the >>>>>>>>>>>> key. That >>>>>>>>>>>> means, if there is no dictionary registered for the site, the >>>>>>>>>>>> behavior of >>>>>>>>>>>> Chrome will not change while browsing the site. Also this feature >>>>>>>>>>>> is only >>>>>>>>>>>> usable within a secure-context so this feature will not increase >>>>>>>>>>>> the risk >>>>>>>>>>>> of having network proxies meddle with the content’s encoding. For >>>>>>>>>>>> enterprises that have deployed HTTPS-intercepting proxies that do >>>>>>>>>>>> not >>>>>>>>>>>> properly handle unknown encodings there is an enterprise policy >>>>>>>>>>>> exposed to >>>>>>>>>>>> disable the feature. The feature is currently enabled only over >>>>>>>>>>>> connections >>>>>>>>>>>> using a well-known trust root for the secure connection which >>>>>>>>>>>> eliminates >>>>>>>>>>>> the risk of security devices and proxies breaking traffic. The >>>>>>>>>>>> roll-out >>>>>>>>>>>> plan for production has steps to remove the trust root restriction >>>>>>>>>>>> and >>>>>>>>>>>> enable support in enterprise environments where intercepting >>>>>>>>>>>> proxies are >>>>>>>>>>>> common. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Gecko: Positive ( >>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/771) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WebKit: Positive ( >>>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/160) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Web developers: Positive >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Other signals: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ergonomics >>>>>>>>>>>> >>>>>>>>>>>> To reduce memory usage in network services, dictionary metadata >>>>>>>>>>>> is stored in a database on disk. And to avoid performance >>>>>>>>>>>> degradation for >>>>>>>>>>>> normal requests that do not use a dictionary, the reading of this >>>>>>>>>>>> metadata >>>>>>>>>>>> is designed not to block network requests. In other words, if the >>>>>>>>>>>> reading >>>>>>>>>>>> of metadata from the database is not completed before the request >>>>>>>>>>>> header is >>>>>>>>>>>> ready to be sent to the server, the dictionary may not be used >>>>>>>>>>>> even if it >>>>>>>>>>>> is already registered in the database. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Activation >>>>>>>>>>>> >>>>>>>>>>>> To adopt this feature, web developers need to make changes in >>>>>>>>>>>> their web servers or build processes for static resources. >>>>>>>>>>>> Currently there >>>>>>>>>>>> is no major server software which directly supports compression >>>>>>>>>>>> dictionaries. Some CDNs have shared interest in supporting shared >>>>>>>>>>>> dictionary compression (e.g. publicly mentioned >>>>>>>>>>>> <https://blog.cloudflare.com/this-is-brotli-from-origin/#:~:text=One%20development%20that%20we%27re%20particularly%20focused%20on%20is%20shared%20dictionaries%20with%20Brotli.> >>>>>>>>>>>> in a blog post by Cloudflare). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Security >>>>>>>>>>>> >>>>>>>>>>>> Chrome registers the response as a dictionary only when the >>>>>>>>>>>> response is CORS-readable from the document origin. Also we use a >>>>>>>>>>>> registered dictionary to decompress the response only when the >>>>>>>>>>>> response is >>>>>>>>>>>> CORS-readable from the document origin. Additionally, the >>>>>>>>>>>> dictionary and >>>>>>>>>>>> the compressed resource are required to be from the same origin as >>>>>>>>>>>> each >>>>>>>>>>>> other. So this should not introduce any new attack vector of >>>>>>>>>>>> information >>>>>>>>>>>> leaks. The dictionaries are partitioned with the storage cache >>>>>>>>>>>> and are cleared whenever cookies or cache is cleared to ensure >>>>>>>>>>>> that the >>>>>>>>>>>> dictionaries can not be abused as a tracking vector. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> WebView application risks >>>>>>>>>>>> >>>>>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>>>>> applications? >>>>>>>>>>>> >>>>>>>>>>>> No >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Goals for experimentation >>>>>>>>>>>> >>>>>>>>>>>> We would like to collect feedback on the updated API design of >>>>>>>>>>>> Compression Dictionary Transport feature. Also, we would like to >>>>>>>>>>>> continue >>>>>>>>>>>> some experiments using this feature to measure its performance >>>>>>>>>>>> impact. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The difference from the previous Origin Trial: >>>>>>>>>>>> >>>>>>>>>>>> - Renamed the link rel attribute for fetching the dictionary >>>>>>>>>>>> from "dictionary" to "compression-dictionary". >>>>>>>>>>>> >>>>>>>>>>>> - Using "dcb" and "dcz" content encoding in place of "br-d" and >>>>>>>>>>>> "zstd-d". The new encodings incorporate the dictionary hash. >>>>>>>>>>>> >>>>>>>>>>>> - Removed the dictionary hash check logic using the >>>>>>>>>>>> "Content-Dictionary" response header, and instead checking the >>>>>>>>>>>> hash within >>>>>>>>>>>> the encoded response body. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ongoing technical constraints >>>>>>>>>>>> >>>>>>>>>>>> None >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Debuggability >>>>>>>>>>>> >>>>>>>>>>>> We have introduced chrome://net-internals/#sharedDictionary. >>>>>>>>>>>> Using it, web developers can manage the registered dictionaries. >>>>>>>>>>>> Also web >>>>>>>>>>>> developers can check the related HTTP request and response headers >>>>>>>>>>>> (Use-As-Dictionary, Available-Dictionary, Accept-Encoding, >>>>>>>>>>>> Content-Encoding). >>>>>>>>>>>> >>>>>>>>>>>> Any errors in processing responses as a result of dictionary >>>>>>>>>>>> compression issues are reported as issues in Dev Tools. This >>>>>>>>>>>> includes >>>>>>>>>>>> things like dictionary hash mismatches and cors-readability >>>>>>>>>>>> failures. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>> >>>>>>>>>>>> Yes >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>> ? >>>>>>>>>>>> >>>>>>>>>>>> Yes. https://wpt.fyi/results/fetch/compression-dictionary >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Flag name on chrome://flags >>>>>>>>>>>> >>>>>>>>>>>> chrome://flags/#enable-compression-dictionary-transport-backend >>>>>>>>>>>> chrome://flags/#enable-compression-dictionary-transport >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Finch feature name >>>>>>>>>>>> >>>>>>>>>>>> CompressionDictionaryTransportBackend >>>>>>>>>>>> CompressionDictionaryTransport >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>> >>>>>>>>>>>> True >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Tracking bug >>>>>>>>>>>> >>>>>>>>>>>> https://crbug.com/1413922 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Launch bug >>>>>>>>>>>> >>>>>>>>>>>> https://launch.corp.google.com/launch/4266286 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Estimated milestones >>>>>>>>>>>> >>>>>>>>>>>> OriginTrial desktop last >>>>>>>>>>>> >>>>>>>>>>>> 129 >>>>>>>>>>>> >>>>>>>>>>>> OriginTrial desktop first >>>>>>>>>>>> >>>>>>>>>>>> 127 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OriginTrial Android last >>>>>>>>>>>> >>>>>>>>>>>> 129 >>>>>>>>>>>> >>>>>>>>>>>> OriginTrial Android first >>>>>>>>>>>> >>>>>>>>>>>> 127 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>> >>>>>>>>>>>> https://chromestatus.com/feature/5124977788977152 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>> >>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/-qYpLo9DTjw/m/JX6kbUOtBQAJ >>>>>>>>>>>> >>>>>>>>>>>> Intent to experiment: >>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E/m/oup5DpbxAAAJ >>>>>>>>>>>> >>>>>>>>>>>> Intent to extend Origin Trial: >>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/7YdP2YxRQn4/m/9oPxLDdjAAAJ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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+...@chromium.org. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-UpM8k_NGuqbuA%2BNuC%2BTdGDjGzUt0Fp05Y8pHROjH-WZA%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-UpM8k_NGuqbuA%2BNuC%2BTdGDjGzUt0Fp05Y8pHROjH-WZA%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 blink-dev+...@chromium.org. >>>>>>>>> >>>>>>>>> >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f9f7a485-94d3-45cf-a0b1-3021c6d7526a%40chromium.org >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f9f7a485-94d3-45cf-a0b1-3021c6d7526a%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/CADk0S-VSKcS1D%2BC3kQVAzktZFxTnzXUJ-iEgbSi%3DR1u9qLDWPw%40mail.gmail.com.
