Intent to Implement and Ship: WritableStream controller AbortSignal

298 views
Skip to first unread message

Nidhi Jaju

unread,
Aug 31, 2021, 11:15:00 AM8/31/21
to blink-dev, Yutaka Hirano, Adam Rice

Contact emails

nidh...@chromium.org, ri...@chromium.org, yhi...@chromium.org

Explainer

https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md

Specification

https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. This change permits an underlying sink to rapidly abort an ongoing write or close when requested by the writer.


Previously, when writer.abort() was called, a long-running write would still have to continue to completion before the stream could be aborted. With this change, the write can be aborted immediately. In addition to being exposed to streams authored in JavaScript, this facility will also be used by platform-provided streams such as WebTransport.


Blink component

Blink>Network>StreamsAPI

TAG review

Not needed as this is an incremental improvement to an existing feature.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk because streams has already been standardised for a long time (since around 2014). Other browsers have implemented other parts of the standard, and they will most likely also adapt this feature as well soon.


Gecko: Positive (https://github.com/whatwg/streams/pull/1132#issuecomment-867114529) Mozilla is supportive of Streams but has not yet shipped WritableStream. It is expected that they will include this feature when they do. They have also expressed interest in implementing WebTransport, and therefore are supportive of this feature.

WebKit: No signal

Web developers: No signals

Ergonomics

A lot of design efforts have been made into making the streams API easy to use. Additionally, this feature is only a small change to the existing streams API that developers are used to. An underlying sink which doesn't observe the controller.signal will continue to have the existing behavior.



Debuggability

No special support needed.


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

Yes

Flag name


Requires code in //chrome?

False

Tracking bug

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

Patch
https://chromium-review.googlesource.com/c/chromium/src/+/3127824

Estimated milestones

M95

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5698931422920704

This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Sep 1, 2021, 9:28:17 AM9/1/21
to Nidhi Jaju, blink-dev, Yutaka Hirano, Adam Rice
On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju <nidh...@chromium.org> wrote:


Specification

https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. This change permits an underlying sink to rapidly abort an ongoing write or close when requested by the writer.


Previously, when writer.abort() was called, a long-running write would still have to continue to completion before the stream could be aborted. With this change, the write can be aborted immediately.


Am I correct in assuming that the stream developer would have to change their code in order for that to happen, and if they won't, the current behavior won't change?
 

In addition to being exposed to streams authored in JavaScript, this facility will also be used by platform-provided streams such as WebTransport.


Blink component

Blink>Network>StreamsAPI

TAG review

Not needed as this is an incremental improvement to an existing feature.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk because streams has already been standardised for a long time (since around 2014). Other browsers have implemented other parts of the standard, and they will most likely also adapt this feature as well soon.


Gecko: Positive (https://github.com/whatwg/streams/pull/1132#issuecomment-867114529) Mozilla is supportive of Streams but has not yet shipped WritableStream. It is expected that they will include this feature when they do. They have also expressed interest in implementing WebTransport, and therefore are supportive of this feature.

While such comments don't typically count as a position, combining them with https://github.com/mozilla/standards-positions/issues/167 seems reasonable, given the size of this change.
 

WebKit: No signal

Have you reached out? https://bit.ly/blink-signals
 

Web developers: No signals

Have you reached out? https://goo.gle/developer-signals
 

Ergonomics

A lot of design efforts have been made into making the streams API easy to use. Additionally, this feature is only a small change to the existing streams API that developers are used to. An underlying sink which doesn't observe the controller.signal will continue to have the existing behavior.



Debuggability

No special support needed.


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

Yes

Flag name


Requires code in //chrome?

False

Tracking bug

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

Patch
https://chromium-review.googlesource.com/c/chromium/src/+/3127824

Estimated milestones

M95

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5698931422920704

This intent message was generated by Chrome Platform Status.

--
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/CAMZNYAP-Of819oOp4yq8vRdzx78UUCPj9YKJqx4ZwLj_YsN%3D-Q%40mail.gmail.com.

Alex Russell

unread,
Sep 1, 2021, 9:54:23 AM9/1/21
to Yoav Weiss, Nidhi Jaju, blink-dev, Yutaka Hirano, Adam Rice
Incremental features often benefit from TAG guidance. I'd feel better if this intent at least cited prior TAG reviews in this area or filed an FYI (with potential for TAG to request full review).

If it was covered in a previous review of WritableStreams, that would also be good to know.

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

Nidhi Jaju

unread,
Sep 1, 2021, 11:23:02 PM9/1/21
to Alex Russell, Yoav Weiss, blink-dev, Yutaka Hirano, Adam Rice
On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <sligh...@chromium.org> wrote:
Incremental features often benefit from TAG guidance. I'd feel better if this intent at least cited prior TAG reviews in this area or filed an FYI (with potential for TAG to request full review).

If it was covered in a previous review of WritableStreams, that would also be good to know.

This feature wasn't covered in a previous review of WritableStreams, so I have filed a new TAG review: https://github.com/w3ctag/design-reviews/issues/672
 

On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss <yoav...@chromium.org> wrote:


On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju <nidh...@chromium.org> wrote:


Specification

https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal

Summary

The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. This change permits an underlying sink to rapidly abort an ongoing write or close when requested by the writer.


Previously, when writer.abort() was called, a long-running write would still have to continue to completion before the stream could be aborted. With this change, the write can be aborted immediately.


Am I correct in assuming that the stream developer would have to change their code in order for that to happen, and if they won't, the current behavior won't change?

Yes, that's correct.

 

In addition to being exposed to streams authored in JavaScript, this facility will also be used by platform-provided streams such as WebTransport.


Blink component

Blink>Network>StreamsAPI

TAG review

Not needed as this is an incremental improvement to an existing feature.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk because streams has already been standardised for a long time (since around 2014). Other browsers have implemented other parts of the standard, and they will most likely also adapt this feature as well soon.


Gecko: Positive (https://github.com/whatwg/streams/pull/1132#issuecomment-867114529) Mozilla is supportive of Streams but has not yet shipped WritableStream. It is expected that they will include this feature when they do. They have also expressed interest in implementing WebTransport, and therefore are supportive of this feature.

While such comments don't typically count as a position, combining them with https://github.com/mozilla/standards-positions/issues/167 seems reasonable, given the size of this change.
 

WebKit: No signal

Have you reached out? https://bit.ly/blink-signals

I have requested for WebKit's position here: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031977.html
 
 

Web developers: No signals

Have you reached out? https://goo.gle/developer-signals

Mattias Buelens has shown positive support here: https://github.com/whatwg/streams/issues/1015#issuecomment-531188273 
 

Hopefully, this addresses your questions/concerns. Thank you!

Best regards,
Nidhi 

Yutaka Hirano

unread,
Sep 2, 2021, 12:35:13 AM9/2/21
to Nidhi Jaju, Alex Russell, Yoav Weiss, blink-dev, Adam Rice
Please also note that, while we believe the mechanism can be useful for some web developers, our main motivation at this point is WebTransport (#260, #295).

Chris Harrelson

unread,
Sep 2, 2021, 3:32:46 PM9/2/21
to Nidhi Jaju, Alex Russell, Yoav Weiss, blink-dev, Yutaka Hirano, Adam Rice
That said, could you comment on issue 167 giving at least an FYI that this intent is happening?
 

Reilly Grant

unread,
Sep 2, 2021, 3:36:00 PM9/2/21
to Chris Harrelson, Nidhi Jaju, Alex Russell, Yoav Weiss, blink-dev, Yutaka Hirano, Adam Rice
The Web Serial API is also interested in this capability. See the note on the abort algorithm when initializing the WritableStream.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome


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

Nidhi Jaju

unread,
Sep 2, 2021, 9:45:04 PM9/2/21
to Chris Harrelson, Alex Russell, Yoav Weiss, blink-dev, Yutaka Hirano, Adam Rice, Reilly Grant

Nidhi Jaju

unread,
Sep 15, 2021, 10:01:29 PM9/15/21
to Chris Harrelson, Alex Russell, Yoav Weiss, blink-dev, Yutaka Hirano, Adam Rice, Reilly Grant
Hi,

Just as an update, we have received some feedback on our TAG review (https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419), and hence we are having some discussions and deciding on next best steps accordingly.

Best regards,
Nidhi

Yoav Weiss

unread,
Oct 7, 2021, 3:40:59 AM10/7/21
to blink-dev, Nidhi Jaju, Alex Russell, Yoav Weiss, blink-dev, Yutaka Hirano, Adam Rice, Reilly Grant, Chris Harrelson
After talking to Nidhi offline, we can consider this intent on hold until the feedback is addressed.

On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
Hi,

Just as an update, we have received some feedback on our TAG review (https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419), and hence we are having some discussions and deciding on next best steps accordingly.

Best regards,
Nidhi
On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju <nidh...@chromium.org> wrote:
On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant <rei...@chromium.org> wrote:
The Web Serial API is also interested in this capability. See the note on the abort algorithm when initializing the WritableStream.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome


On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <chri...@chromium.org> wrote:
On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju <nidh...@chromium.org> wrote:
On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <sligh...@chromium.org> wrote:
Incremental features often benefit from TAG guidance. I'd feel better if this intent at least cited prior TAG reviews in this area or filed an FYI (with potential for TAG to request full review).

If it was covered in a previous review of WritableStreams, that would also be good to know.

This feature wasn't covered in a previous review of WritableStreams, so I have filed a new TAG review: https://github.com/w3ctag/design-reviews/issues/672
 
On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju <nidh...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Hopefully, this addresses your questions/concerns. Thank you!

Best regards,
Nidhi 

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Nidhi Jaju

unread,
Nov 24, 2021, 2:57:12 AM11/24/21
to blink-dev, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant, Chris Harrelson, Yoav Weiss
Hi all,

Another update: based on the feedback we received from TAG as previously mentioned, we decided to remove the abortReason from WritableStreamDefaultController which was initially proposed, and instead add an "abort reason" property to AbortSignal which was specced in https://github.com/whatwg/dom/pull/1027. Related to this on the interface side, the static AbortSignal.abort() as well as the AbortController.abort() now take an optional reason argument. Gecko and WebKit folks and some developers have also expressed implementer's interest on the PR, and some have gone on to update their browser implementation/polyfills already.

This was also integrated into the Streams standard in https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API is connected to various different standards, so there is also an ongoing effort to update those affected specs as well here.)

I would like to resume the intent process based on these updates. Please let me know if you have any questions or thoughts.

Thank you!

Best regards,
Nidhi

On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss <yoav...@chromium.org> wrote:
After talking to Nidhi offline, we can consider this intent on hold until the feedback is addressed.

On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
Hi,

Just as an update, we have received some feedback on our TAG review (https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419), and hence we are having some discussions and deciding on next best steps accordingly.

Best regards,
Nidhi
On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju <nidh...@chromium.org> wrote:
On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant <rei...@chromium.org> wrote:
The Web Serial API is also interested in this capability. See the note on the abort algorithm when initializing the WritableStream.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome


On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson <chri...@chromium.org> wrote:
On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju <nidh...@chromium.org> wrote:
On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <sligh...@chromium.org> wrote:
Incremental features often benefit from TAG guidance. I'd feel better if this intent at least cited prior TAG reviews in this area or filed an FYI (with potential for TAG to request full review).

If it was covered in a previous review of WritableStreams, that would also be good to know.

This feature wasn't covered in a previous review of WritableStreams, so I have filed a new TAG review: https://github.com/w3ctag/design-reviews/issues/672
 
On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju <nidh...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.

Hopefully, this addresses your questions/concerns. Thank you!

Best regards,
Nidhi 

--
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.

--
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.
--
Google Logo
Nidhi Jaju
Software Engineer
nidh...@google.com
+81 3-5860-5522

Yoav Weiss

unread,
Nov 24, 2021, 3:13:14 AM11/24/21
to blink-dev, Nidhi Jaju, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant, Chris Harrelson, Yoav Weiss
Thanks for addressing the TAG's feedback!


On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
Hi all,

Another update: based on the feedback we received from TAG as previously mentioned, we decided to remove the abortReason from WritableStreamDefaultController which was initially proposed, and instead add an "abort reason" property to AbortSignal which was specced in https://github.com/whatwg/dom/pull/1027. Related to this on the interface side, the static AbortSignal.abort() as well as the AbortController.abort() now take an optional reason argument. Gecko and WebKit folks and some developers have also expressed implementer's interest on the PR, and some have gone on to update their browser implementation/polyfills already.

Any specifics? Does this mean other browsers are now also shipping AbortSignal for WritableStreams? Or did they just update their current AbortSignal implementation with an "abort reason"?
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Hopefully, this addresses your questions/concerns. Thank you!

Best regards,
Nidhi 

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Nidhi Jaju

unread,
Nov 24, 2021, 4:50:42 AM11/24/21
to Yoav Weiss, blink-dev, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant, Chris Harrelson
On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss <yoav...@chromium.org> wrote:
Thanks for addressing the TAG's feedback!


On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
Hi all,

Another update: based on the feedback we received from TAG as previously mentioned, we decided to remove the abortReason from WritableStreamDefaultController which was initially proposed, and instead add an "abort reason" property to AbortSignal which was specced in https://github.com/whatwg/dom/pull/1027. Related to this on the interface side, the static AbortSignal.abort() as well as the AbortController.abort() now take an optional reason argument. Gecko and WebKit folks and some developers have also expressed implementer's interest on the PR, and some have gone on to update their browser implementation/polyfills already.

Any specifics? Does this mean other browsers are now also shipping AbortSignal for WritableStreams? Or did they just update their current AbortSignal implementation with an "abort reason"?

Ah, sorry for the unclearness. I mean they (i.e. WebKit, Deno, and almost Node.js) have updated their current AbortSignal implementation with an "abort reason". As far as I'm aware, the signals related to shipping AbortSignal for WritableStreams itself remain unchanged from earlier on in this thread.
 
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.

Hopefully, this addresses your questions/concerns. Thank you!

Best regards,
Nidhi 

--
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.

--
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.

Yoav Weiss

unread,
Nov 24, 2021, 5:06:22 AM11/24/21
to Nidhi Jaju, blink-dev, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant, Chris Harrelson
LGTM1


On Wed, Nov 24, 2021, 10:50 Nidhi Jaju <nidh...@chromium.org> wrote:
On Wed, Nov 24, 2021 at 1:43 PM Yoav Weiss <yoav...@chromium.org> wrote:
Thanks for addressing the TAG's feedback!


On Wednesday, November 24, 2021 at 8:57:12 AM UTC+1 Nidhi Jaju wrote:
Hi all,

Another update: based on the feedback we received from TAG as previously mentioned, we decided to remove the abortReason from WritableStreamDefaultController which was initially proposed, and instead add an "abort reason" property to AbortSignal which was specced in https://github.com/whatwg/dom/pull/1027. Related to this on the interface side, the static AbortSignal.abort() as well as the AbortController.abort() now take an optional reason argument. Gecko and WebKit folks and some developers have also expressed implementer's interest on the PR, and some have gone on to update their browser implementation/polyfills already.

Any specifics? Does this mean other browsers are now also shipping AbortSignal for WritableStreams? Or did they just update their current AbortSignal implementation with an "abort reason"?

Ah, sorry for the unclearness. I mean they (i.e. WebKit, Deno, and almost Node.js) have updated their current AbortSignal implementation with an "abort reason". As far as I'm aware, the signals related to shipping AbortSignal for WritableStreams itself remain unchanged from earlier on in this thread.

Makes sense, thanks for clarifying!

Mike West

unread,
Nov 24, 2021, 9:18:57 AM11/24/21
to Yoav Weiss, Nidhi Jaju, blink-dev, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant, Chris Harrelson
LGTM2.

Given that this has landed in both DOM and Streams with support from Mozilla, and WebKit has tacitly expressed support via their implementation, this is a pretty reasonable thing for us to follow along with. Thanks for iterating with others in the ecosystem to land on something folks were happy with!

-mike


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

Chris Harrelson

unread,
Nov 24, 2021, 11:21:00 AM11/24/21
to Mike West, Yoav Weiss, Nidhi Jaju, blink-dev, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant
LGTM3

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

Joe Medley

unread,
Nov 30, 2021, 3:14:45 PM11/30/21
to Chris Harrelson, Mike West, Yoav Weiss, Nidhi Jaju, blink-dev, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant
In which version is this shipping?
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


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

Nidhi Jaju

unread,
Dec 7, 2021, 2:04:40 AM12/7/21
to Joe Medley, Chris Harrelson, Mike West, Yoav Weiss, blink-dev, Alex Russell, Yutaka Hirano, Adam Rice, Reilly Grant
Hi Joe,

I'm really sorry for the delay in my reply!
These changes will be shipped in Chrome 98.

Best regards,
Nidhi
Reply all
Reply to author
Forward
0 new messages