User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

1. Load the attached add-on.
2. Open https://www.wikipedia.org/ in a new tab

Actual results:

size empty

If you disable the code chrome.webRequest.onHeadersReceived.addListener(onHeadersReceived, {"urls": ["https://www.wikipedia.org/"]});
then size is not empty.

This is from bug 1810344.

Hello,

I reproduced the issue on the latest Nightly (111.0a1/20230208214144), Beta (110.0/20230206190557) and Release (109.0.1/20230127170202) under Windows 10 x64 and macOS 11.3.1.

Using the attached extension and accessing https://www.wikipedia.org/ in a new tab will log “size empty” in the add-on debug console.

Furthermore, commenting out the snippet from Comment 0, will return “size not empty” as described.

For more details, see the attached screenshots.

Update:

I noticed that when using the extension with the commented out code, immediately after using the extension without the commented out code, “size empty” might be returned.
Clearing data from about:preferences#privacy “Cookies and Site Data” will cause the correct behavior as per Comment 2.

Should the doc also be updated, to include the requestSize and responseSize?

(In reply to kernp25 from comment #6)

Should the doc also be updated, to include the requestSize and responseSize?

Probably yes, but let's see whether the functionality actually works before documenting it.
It was added in bug 1545423 but not documented.

Luca to investigate how feasible it is to support these properties. If there is no straightforward path forwards for this API, then we can drop the API since it was never documented and apparently broken.

requestSize sounds like something that should certainly be available at the time of onHeadersReceived,
responseSize is not guaranteed to be available, but can be derived from the Content-Type header in most cases.

Verified by modifying test_ext_webRequest_requestSize.js to add an onHeadersReceived handler that duplicates the onBeforeSendHeaders handler. The fix may be to clear cached values during "error" and "stop" in ChannelWrapper. I think it's probably fine to wholesale clear cached values in those events since the request is finished, but not entirely sure.