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-rjcfvCkEGB1jPJHO3K6bQkkCEi6LYwpLZA%2BuiMOMSPFSFQ%40mail.gmail.com.
