feat(har): calculate `request.headerSize`, `response.headerSize`, and `response._transferSize` for `WebSocket` by dcrousso · Pull Request #41091 · microsoft/playwright

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) · 2026-06-02T03:03:59Z

No description provided.

Yury Semikhatsky (yury-s) · 2026-06-02T17:52:29Z

+ data,
+ });
+ updateTime(timestamp);
+ updateTransferSize(opcode, data);


This is getting added to the response transfer size whereas it should go to the request.

oh lol good point

Yury Semikhatsky (yury-s) · 2026-06-02T17:53:39Z

 eventsHelper.addEventListener(webSocket, network.WebSocket.Events.Request, ({ headers }: { headers: HeadersArray }) => {
 this._recordRequestHeadersAndCookies(harEntry, headers);
+ if (!this._options.omitSizes)
+ harEntry.request.headersSize = network.requestHeadersSize(headers, webSocket.url(), method);


Shouldn't request handshake headersSize be added to the request transfer size?

i originally thought that, but when looking at Request.prototype.async _sizes i saw that it's (manually) calculated as just the sum of the response headers and response body
MDN corroborates this as well <https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/transferSize>
The size includes the response header fields plus the response payload body (as defined by RFC7230).

To make sure I understand this correctly, har file contains _transferSize only for responses, so anything request related is irrelevant, right? I first thought that we'd have _transferSize for request as well, but I don't see such field in har.ts

yes that's my understanding as well
i think the closest equivalent for the request would be something like entry.request.headersSize + entry.request.bodySize

technically _transferSize is a non-standard extension
in WebKit, it's equivalent to entry.response.headersSize + entry.response.bodySize so unless Chromium is using it to expose some special info then it might just be a "shortcut" to avoid having to do that math 😅

Yury Semikhatsky (yury-s) · 2026-06-02T17:59:41Z

+ { type: 'receive', opcode: 2, data: incoming },
+ ]);
+ for (const m of messages) {
+ expect(m.time).toBeGreaterThanOrEqual(beforeMs / 1000 - 1);


m.time comes straight from CDP Network.webSocketFrameSent.timestamp in Chromium, which is a MonotonicTime (seconds since an arbitrary process origin), I don't think we can safely compare it with the wall time here. Do we use walltime in other places in har? If so, websockets should be aligned to, otherwise compare time delta here.

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
Network.webSocketWillSendHandshakeRequest.wallTime + (Network.webSocketFrame{Sent,Received}.timestamp - Network.webSocketWillSendHandshakeRequest.timestamp)
in Playwright we do this via WebSocket.prototype._toWallTime
Do we use walltime in other places in har?
there are a bunch of different time values within HAR
startDateTime: when the request first began (which is being changed to use a wallTime in feat(har): use engine timestamps instead of server Date #41082)
time: the total time taken from intial request to final response
timings: an object showing how much time was taken for each portion of the request
_monotonicTime: how long since the playwright process was started
i can further dig into whether the time for each WebSocket frame should be a WallTime or timestamp/MonotonicTime
at the very least, Firefox seems to send it as a WallTime (see the PR_Now() call inside WebSocketFrame)

my understanding of the Chromium (and WebKit) protocols is that it's actually meant to be used as a delta from the timestamp (and wallTime) of Network.webSocketWillSendHandshakeRequest
This may well be this case, but har file doesn't have to inherit that behavior. As a user of har I'd expect all wall time timestamps to be on the same timeline, so that I could compare them. If we need an extra step in Chromium to convert from time since webSocketWillSendHandshakeRequest to wall time, let's do it in the browser-specific code?

we already have this conversion code in WebSocket.prototype._toWallTime but yeah i can move it to Chromium and WebKit code instead

Yury Semikhatsky (yury-s) · 2026-06-02T18:03:28Z

+ if (this._options.omitSizes)
+ return;
+
+ harEntry.response._transferSize = Math.max(0, harEntry.response._transferSize!) + ((opcode === 1) ? Buffer.byteLength(data, 'utf8') : base64ByteLength(data));


_transferSize counts payload bytes only, not frame overhead.
WebSocket framing adds a 2–14 byte header per frame (plus a 4-byte mask for client -> server frames). The computed value is payload-only, so it'll under-report vs. an actual on-wire transfer size. If we we can't compute it more accurately, it may be acceptable as an approximation, but worth a comment.

great point! ill look into this a bit more and see if i can get it more accurate (or as you suggest add a comment if i cant)

Yury Semikhatsky (yury-s) · 2026-06-02T21:15:25Z

+
+ // If the payload is more than 125 bytes then add either 2 or 8 more bytes depending on how long the payload is.
+ if (length > 2 ** 16)
+ headerSize += 8;


a comment on where this number comes from?

this is from the same URL as above but yeah i can repeat it here too

Yury Semikhatsky (yury-s) · 2026-06-02T21:20:00Z

+ else if (length > 125)
+ headerSize += 2;
+
+ // The number of bytes needed for the mask are not included as that information is not exposed via any protocol.


Chromium exposes mask: boolean field. Can mask size vary or it's always 4-bytes if present? Perhaps we can easily add similar information to wk and ff? I mean if we are anyway try to provide more accurate size estimate, we should probably support that too.

oh neat! i didnt notice that. great catch! ill plumb that through and see what i can do to get any similar info from WebKit and Firefox
yes it's either 0 or 4 bytes depending on whether mask is false or true

actually i think we can always assume this as it seems to be required for the client to send a masked frame to the server <https://www.rfc-editor.org/info/rfc6455/#section-5.1>:
a client MUST mask all frames that it sends to the server

… `response._transferSize` for `WebSocket`

github-actions · 2026-06-02T23:13:21Z

Test results for "MCP"

7230 passed, 1103 skipped

Merge workflow run.

github-actions · 2026-06-02T23:15:56Z

Test results for "tests 1"

2 flaky

⚠️ [firefox-library] › library/har-websocket.spec.ts:313 › should record websocket connection failure `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39545 passed, 775 skipped

Merge workflow run.

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 03:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch 2 times, most recently from 2f828b3 to f0088f6Compare June 2, 2026 15:58

This comment has been minimized.
Sign in to view

Yury Semikhatsky (yury-s) reviewed Jun 2, 2026
View reviewed changes

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from f0088f6 to ff814afCompare June 2, 2026 19:36

Devin Rousso (dcrousso) requested a review from Yury Semikhatsky (yury-s)June 2, 2026 19:36

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from ff814af to d2bb0b9Compare June 2, 2026 20:03

This comment has been minimized.
Sign in to view

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from d2bb0b9 to 9e4bf7bCompare June 2, 2026 21:03

Yury Semikhatsky (yury-s) approved these changes Jun 2, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

feat(har): calculate request.headerSize, response.headerSize, and…
b6d29ab
… `response._transferSize` for `WebSocket`

Devin Rousso (dcrousso)force-pushed the feat-har-WebSocket-sizes branch from 9e4bf7b to b6d29abCompare June 2, 2026 22:32

Devin Rousso (dcrousso) merged commit 426cc4e into microsoft:mainJun 3, 2026
50 checks passed

Devin Rousso (dcrousso) deleted the feat-har-WebSocket-sizes branch June 3, 2026 00:36

This was referenced Jun 3, 2026
[Ports]: Backport client side changes for 1.61 microsoft/playwright-python#3070
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-java#1917
Closed
[Ports]: Backport client side changes for 1.61 microsoft/playwright-dotnet#3312
Closed

Uh oh!

Conversation

Devin Rousso (dcrousso) commented Jun 2, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Yury Semikhatsky (yury-s)Jun 2, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

github-actionsBot commented Jun 2, 2026

Test results for "MCP"

Uh oh!

github-actionsBot commented Jun 2, 2026

Test results for "tests 1"

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Devin Rousso (dcrousso) commented Jun 2, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Yury Semikhatsky (yury-s)Jun 2, 2026•
edited
Loading

Yury Semikhatsky (yury-s)Jun 2, 2026•
edited
Loading