On Tue, 27 Jun 2023 at 11:42, Adam Rice <ri...@chromium.org> wrote: > Our mitigations if a serious compatibility issue should occur are more > effective with Chrome. If we discovered we needed to urgently disable zstd > we could do it with a config push. However, in the case of WebView every > app would have to start at least once in the broken configuration before > the config push would take effect. >
This applies to every finch experiment in WebView, whether it's a killswitch or a launch. Rolling it out later in WebView just means we'll get any feedback about issues in WebVIew later. > For this reason, I feel it is safer to enable it in Chrome first to > achieve confidence that there aren't going to be any issues. However, there > is nothing technically stopping us from enabling it in WebView at the same > time if that is the consensus. > > On Tue, 27 Jun 2023 at 23:37, Torne (Richard Coles) <to...@chromium.org> > wrote: > >> Unless you have specific reasons to believe that there are going to be >> compatibility issues that are specific to WebView and a plan for how >> they're going to be addressed, we would strongly prefer that the rollout >> happens at the same time for WebView. >> >> On Tue, 27 Jun 2023 at 08:10, Mihai Cîrlănaru <m...@chromium.org> wrote: >> >>> Thank you for the clarification, Nidhi! >>> >>> Could you expand on the compatibility issues that might come up here? >>> Given the overlap WebView has with Chrome in terms of source code, these >>> might apply to both. Nevertheless, having WebView in the experiments from >>> the start will help uncover WebView specific issues early and ensure a >>> timely release (as opposed to Brotli support >>> <https://chromestatus.com/feature/5420797577396224>) and a unified >>> narrative, i.e. "*Zstd content-encoding support available for Android >>> (Chrome and WebView)*". >>> >>> On Tuesday, June 27, 2023 at 5:19:08 AM UTC+2 Nidhi Jaju wrote: >>> >>>> Thank you for reaching out, Mihai and Peter! >>>> Our plan is to support this feature in WebView as well, but most likely >>>> a few milestones after M117 so that we can deal with any compatibility >>>> issues separately. I'll share further updates when we have more information >>>> on the WebView rollout plan. >>>> >>>> Thanks, >>>> Nidhi >>>> >>>> On Mon, Jun 26, 2023 at 7:27 PM Peter Beverloo <pe...@chromium.org> >>>> wrote: >>>> >>>>> Thank you for sharing the I2P Nidhi! What are your plans regarding >>>>> supporting this feature in Android WebView? We're just rolling out support >>>>> for Brotli there and we should aim for it to be on par with the browser >>>>> regarding supported compression algorithms. >>>>> >>>>> Thanks, >>>>> Peter >>>>> >>>>> >>>>> On Thu, Jun 22, 2023 at 7:05 PM PhistucK <phist...@gmail.com> wrote: >>>>> >>>>>> If/when shipping, just remember to add this to the list of "Accepted >>>>>> Content-Encodings" that shows up on the developer tools, under the >>>>>> "Network >>>>>> conditions" panel. :) >>>>>> [image: image.png] >>>>>> >>>>>> ☆*PhistucK* >>>>>> >>>>>> >>>>>> On Wed, Jun 21, 2023 at 6:08 PM Dale Curtis <dalecur...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> On Wed, Jun 21, 2023 at 3:18 AM Adam Rice <ri...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Drive by question: Given that the codec is going to be in the >>>>>>>>> browser, are there plans to surface this up to CompressionStreams? >>>>>>>>> (same >>>>>>>>> question applies for Brotli, I suppose) >>>>>>>> >>>>>>>> >>>>>>>> For the zstd Content-Encoding, we will only be linking in the >>>>>>>> decompression part of the zstd library. But for CompressionStreams, >>>>>>>> supporting a format only for decompression and not for compression is >>>>>>>> likely to confuse and frustrate developers. >>>>>>>> >>>>>>> >>>>>>> FWIW, asymmetric codec capabilities are quite common in media and >>>>>>> developers have adapted just fine. E.g., we may only have >>>>>>> hevc/aac/theora >>>>>>> decoding, but not encoding. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> So while I'd like to add Zstd to CompressionStreams, we'll need a >>>>>>>> good justification for the extra binary size increase caused by >>>>>>>> linking in >>>>>>>> the compression code. The same applies to Brotli. >>>>>>>> >>>>>>>> Thanks for the question! >>>>>>>> >>>>>>>> On Wed, 21 Jun 2023 at 18:53, Sangwhan Moon <s...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2023年06月21日 18時02分49秒 (+09:00), Nidhi Jaju wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jun 21, 2023 at 3:35 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jun 21, 2023 at 8:15 AM Nidhi Jaju < >>>>>>>>>> nidhij...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emailsnidhij...@chromium.org >>>>>>>>>>> >>>>>>>>>>> Explainer >>>>>>>>>>> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing >>>>>>>>>>> Specificationhttps://datatracker.ietf.org/doc/html/rfc8878 >>>>>>>>>>> >>>>>>>>>>> Design docs >>>>>>>>>>> https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> Zstandard, or “zstd”, is a data compression mechanism described >>>>>>>>>>> in RFC8878. It is a fast lossless compression algorithm, targeting >>>>>>>>>>> real-time compression scenarios at zlib-level and better compression >>>>>>>>>>> ratios. The "zstd" token was added as an IANA-registered >>>>>>>>>>> Content-Encoding >>>>>>>>>>> token as per >>>>>>>>>>> https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding. >>>>>>>>>>> Adding support for "zstd" as a Content-Encoding will help load >>>>>>>>>>> pages faster >>>>>>>>>>> and use less bandwidth. >>>>>>>>>>> >>>>>>>>>>> Blink componentInternals>Network >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork> >>>>>>>>>>> >>>>>>>>>>> Motivation >>>>>>>>>>> >>>>>>>>>>> Supporting zstd content-encoding in the browser would allow >>>>>>>>>>> sites to spend less time and CPU/power on compression on their >>>>>>>>>>> servers, >>>>>>>>>>> resulting in reduced server costs. There are several published >>>>>>>>>>> benchmarks[i.e. 1 <https://facebook.github.io/zstd/#benchmarks>, >>>>>>>>>>> 2 >>>>>>>>>>> <https://peazip.github.io/fast-compression-benchmark-brotli-zstandard.html>] >>>>>>>>>>> and existing research showing promising potential wins. Zstd is >>>>>>>>>>> roughly >>>>>>>>>>> three times faster than Brotli for decompression. Combined with >>>>>>>>>>> zstd being >>>>>>>>>>> faster at compression, this will result in faster page load times. >>>>>>>>>>> Initial public proposalNone >>>>>>>>>>> >>>>>>>>>>> TAG reviewNone >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> Drive by question: Given that the codec is going to be in the >>>>>>>>> browser, are there plans to surface this up to CompressionStreams? >>>>>>>>> (same >>>>>>>>> question applies for Brotli, I suppose) >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>> >>>>>>>>>>> Risks >>>>>>>>>>> >>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>> >>>>>>>>>>> Servers that have a broken implementation of zstd might exist, >>>>>>>>>>> but the risk of this is small. Additionally, middleware and >>>>>>>>>>> middleboxes >>>>>>>>>>> like virus checkers that intercept HTTPS connections might not >>>>>>>>>>> support >>>>>>>>>>> zstd, but might fail to remove it from the Accept-Encoding header >>>>>>>>>>> in the >>>>>>>>>>> request. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Are we planning to only support this encoding under secure >>>>>>>>>> contexts and/or H2+ to reduce that risk? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, we're only planning to support zstd encoding under secure >>>>>>>>> contexts, same as Brotli. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Gecko*: No signal ( >>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/775) >>>>>>>>>>> >>>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/168) >>>>>>>>>>> >>>>>>>>>>> *Web developers*: Positive (https://crbug.com/1246971) Facebook >>>>>>>>>>> (Yann) and Akamai (Nic) seem to be positive about zstd >>>>>>>>>>> content-encoding >>>>>>>>>>> support in the browser. Facebook is also excited to test the >>>>>>>>>>> feature. >>>>>>>>>>> >>>>>>>>>>> *Other signals*: >>>>>>>>>>> >>>>>>>>>>> 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? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Debuggability >>>>>>>>>>> >>>>>>>>>>> No special support needed. >>>>>>>>>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ?Not yet. >>>>>>>>>>> >>>>>>>>>>> Flag nameZstdContentEncoding >>>>>>>>>>> >>>>>>>>>>> Requires code in //chrome?True >>>>>>>>>>> >>>>>>>>>>> Tracking bug >>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1246971 >>>>>>>>>>> >>>>>>>>>>> Estimated milestones >>>>>>>>>>> Shipping on desktop 117 >>>>>>>>>>> Shipping on Android 117 >>>>>>>>>>> >>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>> https://chromestatus.com/feature/6186023867908096 >>>>>>>>>>> >>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>> >>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>> <https://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 blink-dev+unsubscr...@chromium.org. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%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+unsubscr...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAN%3DdFzxxXGt%2BTscR9zfu-dF38u_E4rQ7ynv8C%3D1C67YPA%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYAN%3DdFzxxXGt%2BTscR9zfu-dF38u_E4rQ7ynv8C%3D1C67YPA%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+unsubscr...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxjsRhddJWgPP%3DHF5dbU9L9feqi369310-kFAzM_R6GAw%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxjsRhddJWgPP%3DHF5dbU9L9feqi369310-kFAzM_R6GAw%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+unsubscr...@chromium.org. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwfV7F4QT_2g_CG9kypeujEKxaQ1MKe5fzVbY4uGSZifLw%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwfV7F4QT_2g_CG9kypeujEKxaQ1MKe5fzVbY4uGSZifLw%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+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JkoEUc77LGtAEMpt%2BQ%2BPeVJ028jbGzNrvM4y%2B09OBrYw%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_JkoEUc77LGtAEMpt%2BQ%2BPeVJ028jbGzNrvM4y%2B09OBrYw%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+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/118f6dad-17e3-4176-a391-04bb3bdfaab8n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/118f6dad-17e3-4176-a391-04bb3bdfaab8n%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/CAEV-rjdn7WquFsepmOvbOn_2jqWDUE2SzPB3j1ecCBN0E3gBFA%40mail.gmail.com.
