WebDriver BiDi network.getData command returns RangeError for specific network response body
Categories
(Remote Protocol :: WebDriver BiDi, defect, P2)
Tracking
(firefox148 fixed)
| Tracking | Status | |
|---|---|---|
| firefox148 | --- | fixed |
People
(Reporter: james.h.evans.jr, Assigned: jdescottes)
References
Details
(Whiteboard: [webdriver:m19][webdriver:relnote])
Attachments
(4 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:145.0) Gecko/20100101 Firefox/145.0
Steps to reproduce:
Execute a script that executes the following WebDriver BiDi commands:
{
"method": "network.addDataCollector",
"params": {
"dataTypes": [ "request", "response" ],
"maxEncodedDataSize": 200000000,
"contexts": [ "<browsing context ID>" ]
}
}
{
"method": "session.subscribe",
"params": {
"events": [
"network.beforeRequestSent",
"network.responseCompleted"
],
"contexts": [ "<browsing context ID>" ]
}
}
{
"method": "browsingContext.navigate",
"params": {
"context": "<browsing context ID>",
"url": "<url>",
"wait": "complete"
}
}
{
"method": "network.getData",
"params": {
"request": "<request ID captured from network.beforeRequestSent event>",
"dataType": "response",
"collector": "<collector ID from Network.addDataCollector",
"disown":true
}
}
The URL being captured is an image, which is just over 1MB in size. Full trace-level log attached.
Actual results:
Received an error from the network.getData command:
{
"type": "error",
"id": <command ID>,
"error": "unknown error",
"message": "RangeError: source array is too long","stacktrace":"decodeResponseChunks@resource://devtools/shared/network-observer/NetworkUtils.sys.mjs:803:11\ngetBytesValue@chrome://remote/content/shared/NetworkResponse.sys.mjs:174:36\ngetBytesValue@chrome://remote/content/shared/NetworkDataBytes.sys.mjs:33:31\ngetData@chrome://remote/content/webdriver-bidi/modules/root/network.sys.mjs:1288:45\nhandleCommand@chrome://remote/content/shared/messagehandler/MessageHandler.sys.mjs:282:33\nexecute@chrome://remote/content/shared/webdriver/Session.sys.mjs:432:32\nonPacket@chrome://remote/content/webdriver-bidi/WebDriverBiDiConnection.sys.mjs:236:37\nonMessage@chrome://remote/content/server/WebSocketTransport.sys.mjs:127:18\nhandleEvent@chrome://remote/content/server/WebSocketTransport.sys.mjs:109:14\n"
}
Expected results:
The command should have succeeded.
Comment 2•3 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•3 months ago
|
Comment 3•3 months ago
|
||
The actual problem seems to come from this line:
const bytes = new Uint8Array(encodedBodySize);
let offset = 0;
for (const chunk of chunks) {
> bytes.set(new Uint8Array(chunk), offset);
offset += chunk.byteLength;
}
The responseCompleted payload for the image is:
1765293660866RemoteAgentDEBUGWebDriverBiDiConnection4af3fd96-ad72-4dfc-8817-593af88d07c9<-{
"type": "event",
"method": "network.responseCompleted",
"params": {
"context": "67ac0405-a7ec-41bb-8818-b3d581d75219",
"isBlocked": false,
"navigation": null,
"redirectCount": 0,
"request": {
"request": "23-e57df0a1-bf14-446b-9b27-fdb25bf6d96a",
"url": "http://localhost:52037/images/kitten.png",
"method": "GET",
"bodySize": 0,
"headersSize": 481,
"headers": [
{
"name": "Host",
"value": {
"type": "string",
"value": "localhost:52037"
}
},
{
"name": "User-Agent",
"value": {
"type": "string",
"value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0"
}
},
{
"name": "Accept",
"value": {
"type": "string",
"value": "image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5"
}
},
{
"name": "Accept-Language",
"value": {
"type": "string",
"value": "en-US,en;q=0.9"
}
},
{
"name": "Accept-Encoding",
"value": {
"type": "string",
"value": "gzip, deflate, br, zstd"
}
},
{
"name": "Referer",
"value": {
"type": "string",
"value": "http://localhost:52037/simpleContent.html"
}
},
{
"name": "Connection",
"value": {
"type": "string",
"value": "keep-alive"
}
},
{
"name": "Sec-Fetch-Dest",
"value": {
"type": "string",
"value": "image"
}
},
{
"name": "Sec-Fetch-Mode",
"value": {
"type": "string",
"value": "no-cors"
}
},
{
"name": "Sec-Fetch-Site",
"value": {
"type": "string",
"value": "same-origin"
}
},
{
"name": "Priority",
"value": {
"type": "string",
"value": "u=5, i"
}
}
],
"cookies": [
],
"destination": "image",
"initiatorType": "img",
"timings": {
"timeOrigin": 0,
"requestTime": 1765293660816.435,
"redirectStart": 0,
"redirectEnd": 0,
"fetchStart": 0,
"dnsStart": 0,
"dnsEnd": 0,
"connectStart": 0,
"connectEnd": 0,
"tlsStart": 0,
"tlsEnd": 0,
"requestStart": 1765293660821.314,
"responseStart": 1765293660863.525,
"responseEnd": 1765293660865.874
}
},
"timestamp": 1765293660866,
"response": {
"url": "http://localhost:52037/images/kitten.png",
"protocol": "http/1.1",
"status": 200,
"statusText": "OK",
"fromCache": false,
"headers": [
{
"name": "Connection",
"value": {
"type": "string",
"value": "keep-alive"
}
},
{
"name": "Server",
"value": {
"type": "string",
"value": "PinchHitter/0.1 .NET/6.0"
}
},
{
"name": "Date",
"value": {
"type": "string",
"value": "Tue, 09 Dec 2025 15:21:00 G12T"
}
},
{
"name": "Content-Type",
"value": {
"type": "string",
"value": "image/png"
}
},
{
"name": "Content-Length",
"value": {
"type": "string",
"value": "1146167"
}
}
],
"mimeType": "image/png",
"bytesReceived": 1146332,
"headersSize": 165,
"bodySize": 1146167,
"content": {
"size": 0
}
}
}
}
Note that "bytesReceived": 1146332 is larger than the "bodySize": 1146167.
Julian, can you please take a look? Thanks!
Comment 4•3 months ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #3)
Note that
"bytesReceived": 1146332is larger than the"bodySize": 1146167.
Well, there are headers that need to be accounted for as well and that fills the gap to bytesReceived. So the problem should be something else. If I have the time next week I can already take a look. Otherwise I'll leave the needinfo for Julian for now.
| Assignee | ||
Comment 5•2 months ago
•
|
||
This is from a couple of different issues.
First we have a regression from Bug 1830230, where we started emitting several "responseContent" events from devtools. With this, we "store" the first responseContent received for the first chunk of the response, which will have a temporary size, which leads to the source array is too long error. Basically we create an array which only accommodate for the first chunk and when we move on to decode the second chunk we throw.
But even after fixing that I faced another issue when decoding the image, because we hit the engine limitation for apply at https://searchfox.org/firefox-main/rev/e61d59b5c9a651fd7bf28043f87c0dc669833496/devtools/shared/network-observer/NetworkUtils.sys.mjs#870
resolve(String.fromCharCode.apply(this, data));
We need to chunk the calls here to circumvent the issue.
(Note that I'm not setting Bug 1830230 as the regressing bug intentionally, since there was another issue predating this anyway)
| Assignee | ||
Comment 6•2 months ago
|
||
Updated•2 months ago
|
| Assignee | ||
Comment 7•2 months ago
|
||
| Assignee | ||
Updated•2 months ago
|
Comment 9•2 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/713f4620461a
https://hg.mozilla.org/mozilla-central/rev/05aaa12c6e39
Updated•1 month ago
|
Description
•