Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

[Moritz Firsching]

Contact emails

de...@chromium.org, firs...@google.com, lo...@google.com, jy...@google.com

Explainer

https://jpeg.org/jpegxl/

http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

Specification

https://arxiv.org/abs/1908.03565

Summary

JPEG XL is a new royalty-free image codec targeting the image quality as found on the web, providing about ~60% size savings when compared to original JPEG at the same perceptual quality, while supporting modern features like HDR, animation, alpha channel, lossless JPEG recompression, lossless and progressive modes. It is based on Google's PIK and Cloudinary's FUIF, and is in the final steps of standardization with ISO.

This feature enables image/jxl decoding support in the blink renderer.

Blink component

Blink>Image

Motivation

The main motivations for supporting JPEG XL in Chrome are:

 - The improvement in image quality vs image size, about 60% file size savings for the same visual quality (lossy compression of larger originals) when compared to JPEG at the qualities found on the web.

- Improved visual latency by both smaller download sizes and supporting progressive decoding modes.

 - Support for HDR, animation and progressive all together in the same image codec. 

 - Support for lossless-recompressed JPEGs

 - Ecosystem interest in JPEG XL: Several Google teams evaluated using JPEG XL for storing and delivering images, as well as outside of Google: including CDNs interest in storing lossless-recompressed JPEGs as JPEG XL and converting to JPEG on request is the browser doesn't support JXL. Facebook is exploring to use JPEG XL.

Initial public proposal

Support decoding image/jxl behind a feature flag which is turned off by default on all platforms. 

Search tags

jxl

TAG review

Not applicable for image decoders

TAG review status

Not applicable

Risks

Interoperability and Compatibility

JPEG XL is in the final stage ISO standardization. 

Firefox has an open bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

Edge/Safari - no signals yet

Gecko: No signal

WebKit: No signal

Web developers: high interest/many stars in the tracking bug, and there was a separate external crbug requesting the feature. 

A lot of interest on encode.su, r/jpegxl, discord, ...

Is this feature fully tested by web-platform-tests?

No, but planning to have complete tests before shipping. 

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1178040

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5188299478007808

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Thanks for working on this! I'm excited about the possibilities around progressive loading.

It may be interesting to work with the Loading team on complementary image loading primitives that would enable us to get the full benefits from this (e.g. to enable high-quality zooming-in, while reusing already downloaded image bytes)

It may be useful to file for signals at some point: https://bit.ly/blink-signals

[Yoav Weiss]

Belatedly realized that I failed to provide advice to y'all about content negotiation and `<picture>` support.

A lot of what I suggested [1] [2] to the AVIF folks would similarly apply to JXL - basically we want to ensure that both server side and client side selection is possible such that supporting browsers would be served with JXL and non-supporting browsers with other formats that they do support.

--
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/adc4e284-03ae-4431-a4e3-eae4046db821n%40chromium.org.

[Anne van Kesteren]

On Tue, Mar 30, 2021 at 9:20 PM 'Moritz Firsching' via blink-dev
<blin...@chromium.org> wrote:
> Specification
>
> https://arxiv.org/abs/1908.03565

I'm not really sure what the best place to raise this, but raising
this on blink-dev as Chromium seems to be the furthest along with JPEG
XL.

To what extent are
https://w3ctag.github.io/design-principles/#new-data-formats and
https://github.com/annevk/orb/issues/3#issuecomment-779630945 being
considered here? This is the first new format with a new signature
that I know of so ideally we use this opportunity to not further
increase the bad security behavior of the past. As written there I
think at minimum we should require a MIME type in the img element
processing model (similar to SVG) and at best we would also require
CORS (similar to module scripts).

[Yoav Weiss]

On Fri, May 7, 2021 at 11:17 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Mar 30, 2021 at 9:20 PM 'Moritz Firsching' via blink-dev
<blin...@chromium.org> wrote:
> Specification
>
> https://arxiv.org/abs/1908.03565

I'm not really sure what the best place to raise this, but raising
this on blink-dev as Chromium seems to be the furthest along with JPEG
XL.

To what extent are
https://w3ctag.github.io/design-principles/#new-data-formats and
https://github.com/annevk/orb/issues/3#issuecomment-779630945 being
considered here? This is the first new format with a new signature
that I know of

Why is a new signature a requirement for starting to enforce MIME types?

 

so ideally we use this opportunity to not further
increase the bad security behavior of the past. As written there I
think at minimum we should require a MIME type in the img element
processing model

That seems reasonable, but I'd like to hear from folks about the potential deployment hurdles it may pose for serving the format from servers that don't translate e.g. the .jxl extension to the right MIME type.

It may make sense to seed popular servers with that MIME type mapping as early as possible.

(similar to SVG) and at best we would also require
CORS (similar to module scripts).

A CORS requirement would be a significant deployment hurdle, as it would mean that e.g. image CDNs wouldn't be able to automatically serve JXL to supporting browsers unless the markup is modified to match.

 

--
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/CADnb78i7E-KZPpURYgsc78LyasgnJm4aiujSgxetg7bAeYH_vg%40mail.gmail.com.

[Luca Versari]

How is JPEG XL the first new format with a new signature? My understanding is that AVIF's signature is also a new one.

WebP's too, but I suppose that WebP predates these other technologies. 

[Ashley Gullen]

Apologies for bringing back an old thread, but I thought it was important to bring this up here.

I was surprised to read that Google are abandoning their efforts to implement JPEG-XL: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

As I understood it, JPEG-XL brought significant improvements over existing image formats, and had a lot of interest in the technology world. However the reasons cited were apparently lack of benefits and lack of interest.

I for one was interested in this format and the improvements it would bring, and it seems many others are disappointed too.  Can Google explain how they came to this conclusion? How are they evaluating the benefits and interest? Even this intent to prototype lists many of the purported benefits and the extent of the interest, which makes this reversal particularly hard to understand.

--

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/CAMM7wxZEBJ8uf5OB%3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com.

[Jim Bankoski]

Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?

After weighing the data,  we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment.  We'll work to publish data in the next couple of weeks. 

For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.

Jim

[Thomas Steiner]

On Fri, Nov 11, 2022 at 4:58 PM 'Jim Bankoski' via blink-dev <blin...@chromium.org> wrote:

Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?

After weighing the data,  we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment.  We'll work to publish data in the next couple of weeks. 

For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.

JPEG XL Wasm: https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl

[Jerzy Głowacki]

With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?

JPEG XL is much faster than AVIF - JPEG XL encoding is about three times as fast as AVIF [1, 2]. JPEG XL supports progressive decoding and JPEG transcoding, unlike AVIF. JPEG XL is available in Firefox Nightly (under a flag) and it is being implemented by Facebook, Adobe, Intel, Krita, The Guardian, Cloudinary, Shopify and more companies. So there is definitely enough interest from the industry. If JPEG XL was implemented in Chromium, it would quickly boost adoption by CDNs and replace JPEG in a short time thanks to lossless JPEG transcoding capability. So what was the real rationale for dropping JPEG XL support?

As for the WebAssembly implementation, the jxl_dec.wasm file is 821 KB [3] (290 KB gzipped) and it can only run after DOM tree is ready and JS is parsed, so it will never be as performant as the native JPEG XL decoder and it will not work when JS is disabled.

[Arnab Animesh Das]

I won't reiterate most of the stuff as Jerry Glowacki has already mentioned most of it. If you think supporting JPEG XL is an unnecessary burden at least allow passthrough support similar to HEVC. It should require no future maintenance from your end and everybody is happy.

We don't know the exact reason why you are removing it, but if you are worried if they may eat into each others adoption (i.e. AVIF vs JPEG XL) I say that it should be the least of the concerns. Today webp and jpeg is living side by side as they have different use cases. AVIF has different use cases as compared to JPEG XL. AVIF excels at low fidelity standard images with slower encoding times whereas JPEG XL excels at hi fidelity progressive images with faster encoding times while allowing for easy transition from JPEG. Let the end users decide what's best for them.

[Jon Sneyers]

One 'elephant in the room' question that is perhaps uncomfortable but I think it needs to be asked nevertheless, is if and how this "weighing the data" was done in a fair and transparent way without being influenced by conflicts of interest. I observe that several people within the Chrome organization are proverbially wearing two hats: one is to "help the web to evolve" as a developer of the single most important web browser, the other is to push the adoption of codecs they helped create. These two interests can of course be perfectly aligned (as is the case with the AV1 video codec, for example), but they can also conflict.

How can we make sure that this particular decision on JPEG XL gets made in a fair and transparent way? Because as it is right now, there is definitely a perception that this is an instance of the "not invented here" syndrome and that AVIF proponents within Chrome are essentially being prosecutor, judge and executioner at the same time.

Obviously I am a JPEG XL proponent myself so I am biased myself. My personal opinion is that both formats complement one another: AVIF is a great replacement for GIF and WebP while JPEG XL is a great replacement for JPEG and PNG, and both bring substantial improvement to the web platform.

Wouldn't it be wise to invite external experts — who have no particular 'horse in the race', so to speak — to investigate this question, review the existing data, gather their own data, weigh it, and suggest the best way forwards? I think this would be a better approach to make sure that Chrome in the end "does the right thing".

Best,

-Jon.

[Devin Wilson]

Given that AVIF is about 100 times more computationally intensive to encode than JPEG XL for the same quality, have you calculated how many excess tons of carbon dioxide will be emitted thanks to this decision? That would appear to be a significant cost borne by everyone outside of Google.

[Yaowu Xu]

Following Jim’s previous note, here is a link to tests AVIF engineers ran comparing AVIF to JPEG, WebP and JPEG-XL. The tests provide all the necessary code, test sets and parameters to reproduce the test results. Developers are welcome to ask questions and submit feedback to avif-f...@googlegroups.com.  

Apologies for the delay in providing this information.  We wanted to be sure that everyone would be able to duplicate and verify these results for themselves before posting.

[Jerzy Głowacki]

Thank you Yaowu Xu for providing the link to the tests. However, being made by AVIF engineers, aren't they skewed towards AVIF format?

For example, Cloudinary conducted a test with contradictory results, where "JPEG XL can obtain 10 to 15% better compression than AVIF" and "JPEG XL encoding is about three times as fast as AVIF"[1]. Keep in mind that the libjxl implementation is only at version 0.7.0, so there is still room for performance improvement.

In your test results JPEG XL provides more efficient lossless images compression[2]. So why have you dropped JPEG XL support in Chrome when it is a better lossless format, among other features like progressive decoding? Even you colleagues at Google have bet on JPEG XL by developing Attention Center Model with an JPEG XL encoder[3].
Please reconsider your decision.

[Ryan Hitchman]

For the "decoding speed" graphs, it should be noted that a recent commit fixed a performance regression for JXL decode: https://chromium-review.googlesource.com/c/chromium/src/+/4031214 "For large images, this gives a 3x speed-up when decoding."

[Jarek Duda]

If there are objectivity concerns, maybe there available tests of independent sources?

For example Phoronix often uses libjxl in benchmarks - at least for speed getting very different numbers: https://www.phoronix.com/review/aocc4-gcc-clang/3 - maybe there are available other independent tests?

[Tomáš Poledný]

Now you should run your tests again with this:
https://chromium-review.googlesource.com/c/chromium/src/+/4031214

Dne pátek 2. prosince 2022 v 22:20:19 UTC+1 uživatel Jarek Duda napsal:

[⸻ “‪How Things Work‬”]

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - Also requesting a reconsideration of.JXL as a format due to cross-industry interest from companies & consumers alike. Also on the grounds of it being hindered by being buried behind an obscure flag within beta builds :/ 

 
Could just revert the removal till the M111 or 112 builds and see how things stand then, would give time for debate & a more fairer test of market sentiment for this open JPEG standard. 

[Markus Krainz]

I find it very concerning that this decision is has evidently been based on this bogous data: https://storage.googleapis.com/avif-comparison/index.html

1. The speed comparison is based on a buggy and outdated JPEG XL implementation.

2. The filesize comparison is based on a metric that JPEG XL was not tuned for.

On top of that we seem to have completely misjudged ecosystem and industry demand for JPEG XL .

And there seems to have been no consideration for certain features, which I don't want to reiterate here, that AVIF just doesn't support. I think there is a place for JPEG XL alongside AVIF.

I would suggest to halt the removal of the JPEG XL experiment in Chromium until this is addressed to prevent further harm based on bad science.

[Jon Sneyers]

Here are my thoughts on the comparison performed by the AVIF team:

https://cloudinary.com/blog/contemplating-codec-comparisons

I'll copy my conclusion here:

The AVIF team provided a good starting point for doing a data-driven comparison of image formats that can help to clarify the desirability of adding new formats to the web platform. The compression results obtained by the AVIF team do confirm the results we obtained through subjective experiments and our own evaluations based on objective metrics. According to the subset1 results, the encoding speed of JPEG XL s6 is similar to that of AVIF s7 and at these settings, 9 out of the 13 metrics favor JPEG XL. Roughly speaking, at ‘web quality’, according to the best available metric, AVIF gives a compression gain of about 15% over mozjpeg (or more at the very low end of the quality spectrum), and JPEG XL gives a compression gain of about 15% over AVIF (except at the very low end of the quality spectrum). These are the results obtained by the AVIF team, and they do show the value of JPEG XL.

In this contribution, I hope to have made some constructive suggestions on how to further improve the comparison methodology, and on how to interpret the results in the most meaningful way. Through constructive dialogue, we can together make progress on our shared goals: making the web faster, improving the user experience, and promoting royalty-free codecs!

In other words, I think there has been an unfortunate misinterpretation of the data (essentially: because of aggregating in a way that focuses too much on a not-so-relevant part of the plots), which has unfortunately lead to an incorrect decision. I just hope this mistake can still be corrected, preferably before M110 gets released.

[Matt Williams]

Does anyone from chromium/google intend to weigh in on this dispute of the validity of those benchmarks that were used to dismiss jpegXL?
Independent benchmarks are showing that jpegXL is more performant, which would be in DIRECT OPPOSITION to the reasoning mentioned for the removal!

You have angered a large percentage of the developer community with this decision - as is evident from the many stars on the issue tracker, the frequent discussions on major forums, and even press coverage - yet NO representative from google has made any steps to address this and instead have steamed ahead removing the code from the repository.

If google dont intend to respond in this group, and dont intend to respond on the issue tracker - how are we able to reach someone who can reassess and respond to this erroneous decision?

[Yaowu Xu]

Thanks for the feedback regarding speed tests, please see updated decoding timing info on latest builds on more platforms: https://storage.googleapis.com/avif-comparison/decode-timing.html 

[Matt Williams]

Thats a very comprehensive analysis, and I do not understand why it is being ignored.

Unfortunately, it seems like google do not want to participate in any discussion about this. They have now closed any discussion on the issues as "wontfix", despite hundreds of direct complaints on that particular forum.

Many have been enthusiastic about it and have already invested much time and effort into supporting jpegXL. Unfortunately googles market position allows them to quash any codec they desire simply by not supporting it.

I have registered a complaint with the Directorate General for Competition at the European Commission. Hopefully they will encourage Google to open a dialogue with the community about this decision. I suggest that others contact their equivalent representatives and make the same complaint.

[Jon Sneyers]

Thanks for the updated decode timings!

It would be interesting to add decode times for other cases than 8-bit 4:2:0 AVIF. In particular, 4:4:4 is the default in avifenc and cavif, and some people recommend using 10-bit for better compression results also in SDR. It would also be interesting to add decode times for '--faster-decoding' settings of libjxl, as well as recompressed JPEGs, as they decode somewhat faster.

I was doing some additional experimentation using this page: https://sneyers.info/browserspeedtest/index2.html

and I am getting very large differences between 4:2:0 AVIF and 4:4:4 AVIF:

011.jxl: Decode speed: 41.72 MP/s | Fetch: 223.90ms | 100 decodes: 785.40ms
011-fd1.jxl: Decode speed: 45.05 MP/s | Fetch: 180.90ms | 100 decodes: 727.40ms
011-fd2.jxl: Decode speed: 47.10 MP/s | Fetch: 190.90ms | 100 decodes: 695.70ms
011-fd3.jxl: Decode speed: 48.77 MP/s | Fetch: 184.90ms | 100 decodes: 671.90ms
011-8bit420.avif: Decode speed: 86.30 MP/s | Fetch: 200.00ms | 100 decodes: 379.70ms
011-8bit444.avif: Decode speed: 2.91 MP/s | Fetch: 209.00ms | 100 decodes: 11261.10ms
011-10bit.avif: Decode speed: 2.86 MP/s | Fetch: 208.10ms | 100 decodes: 11455.70ms
011-12bit.avif: Decode speed: 2.85 MP/s | Fetch: 215.00ms | 100 decodes: 11507.10ms

This could be a performance bug in the current Chrome integration of AVIF.

Please note that my feedback was not only regarding decode timing.

Best,

-Jon.

[bruno ais (brunoais)]

I tried running the jxl progressive 8MP test on my PC and it looks wrong. I don't see it progressing. So I changed to internet tethering with my phone and I was right! The images are not progressively loading! Was there a mistake somewhere?

From this one example, I believe it's safe to assume that the tests you link are flawed due to being unrealistic. But there's more to it than just that.

JpegXL progressive is designed to be decoded progressively, not in one go. If you are going to decode the whole image in one go, just use the non-progressive option.

Even for the non-progressive version of JpegXL, it's designed to be decoded at the same time it's downloaded. In order to test in the same footing as AVIF, you must consider JXL options for such usage.

For example:

1. You didn't use any of the fast-decoding option of jxl reference encoder. Did you consider that?
2. You didn't specify a colorspace for jxl. Rgb would have been the optimal choice. Did you consider that?
3. You didn't specify a color organization for jxl. XYB would have been a choice to consider. Did you consider that?

There are more elements but I'm not versed in JXL enough to challenge what you provide.

I believe Jon Sneyers could explain even more settings not used.

I also believe that these comments make sense in this context because AVIF was configured with a multitude of options and even set to tune itself specifically for ssim "-a tune=ssim". Given such, to be fair, JXL must also be tuned equivalently!

[⸻ “‪How Things Work‬”]

800 Users with hundreds of comments seem to be distrustful after the previous ones, can't that be considered or taken into account for the request? There are many developers from quite a few big name companies such as Facebook/Meta & Intel too. Also use cases highlighted, such as Medical Imaging. Regardless of how this is spun, it would seem that this format would see widespread adoption & implementation across multiple industries if it were permitted to be enabled by default. 

 

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - One again leaving this link for reference, please reconsider, a lot of work would go to waste when we could all just compromise and improve on the format in the future 

[Albert Andaluz González]

The Chrome status page (https://chromestatus.com/feature/5188299478007808) should now mention that Webkit supports jpeg-xl, at least for Safari 17 beta onwards.

https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes

See also relevant WWDC2023 session (Explore media formats for the web) : 

https://developer.apple.com/videos/play/wwdc2023/10122/ (available 8th June)

[―]

Update: 

 

 

Firefox: 

In testing builds. (Neutral - depending on support from community.) 

Safari (& iOS): 

Currently undergoing testing & implementation as of latest iOS/macOS dev previews. (Positive.) 

Web Developers & Community: 

(Very Positive Support) 

 

 

  - - -   - - -   - - -  

 

Support added by a lot of apps with more showing support should Google Chrome (and ChromeOS) support the format by default & Android Community has requested support for it too alongside some in the Windows Insider Community.

 

This would also be welcomed by the Digital art community, the medical community for scans, and have benefits for streamlining online image storage with a healthy balance of quality vs size taken up.

 

Fwiw, I also support JPG-XL adoption to have healthy competition with AVIF/WebP and I'm neither a developer nor a representative of any company. Just a tech user enthusiast, I've also met countless of people supporting the view. 

 

1,000 in Chromium bug tracker over 500 in Mozilla's Trending Feature Requests, then you have those on reddit and Phoronix wishing to raise their support for the matter.

 

But let's not beat around the bush here, support from Chromium/Chrome can make or break something like this, regardless of whether or not it is logically right to do so, Google knows that fact all too well by now. 

 

[―]

Worth Noting: On top of Apple support, Mozilla is now looking into Jxl integration again. From neutral to positive. 

 

Chrome will need feature parity even if chromium doesn’t have it. 

--

Sent from Gmail Mobile

[Simon Pieters]

On Tue, Jun 20, 2023 at 5:35 PM ― <hmz...@gmail.com> wrote:

Worth Noting: On top of Apple support, Mozilla is now looking into Jxl integration again. From neutral to positive. 

This is incorrect. https://mozilla.github.io/standards-positions/#jpegxl is still neutral.

cheers,

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf2j71RrPYrWOHEXFvkcL6%3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com.

--

Simon Pieters

https://www.mozilla.com/

[Andy Foxman]

Hello,

so when will be the JPEG XL issue reopened?

Request for reopen here: https://bugs.chromium.org/p/chromium/issues/detail?id=1451807

Since Safari added support, I think it deserves new discussion.

Original issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

Thanks.

---

Dne úterý 20. června 2023 v 17:51:12 UTC+2 uživatel Simon Pieters napsal:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf2j71RrPYrWOHEXFvkcL6%3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com.