Network event content.size is always set to 0
Categories
(Remote Protocol :: WebDriver BiDi, defect, P2)
Tracking
(firefox-esr128 unaffected, firefox132 wontfix, firefox133 wontfix, firefox134 wontfix, firefox135 fix-optional)
Tracking | Status | |
---|---|---|
firefox-esr128 | --- | unaffected |
firefox132 | --- | wontfix |
firefox133 | --- | wontfix |
firefox134 | --- | wontfix |
firefox135 | --- | fix-optional |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [webdriver:m15])
Attachments
(1 file)
Since Bug 1882803, we are monitoring http-on-before-stop-request
in content processes in order to fetch the decodedBodySize. However we setup one listener per MessageHandler instance. Observer notifications are scoped to a whole content process, not to a specific browsing context, which means that if we have several MessageHandler instances living in the same process (eg frames in the same domain), we will emit unnecessary events.
We should filter out events which don't match the context we are monitoring.
This currently leads to too much IPC, as well as frequent log pollution such as
console.error: (new InvalidStateError("JSWindowActorChild.sendAsyncMessage: JSWindowActorChild cannot send at the moment", (void 0), 101))
This is very visible on some websites with many shortlived iframes such as https://www.hs.fi/
Assignee | ||
Comment 1•3 months ago
|
||
Reuse the same approach as for our other windowglobal network listener (CachedResourceListener).
The current context is passed as a constructor argument to the BeforeStopRequestListener and observer notifications
for channels which are not related to this context will not generate any event.
Updated•3 months ago
|
Comment 2•3 months ago
|
||
Set release status flags based on info from the regressing bug 1882803
Updated•3 months ago
|
Assignee | ||
Comment 3•3 months ago
|
||
After digging a bit more through the implementation for fetching the decodedBodySize in the content process I found a few additional issues.
First, the NetworkDecodedBodySizeMap has a race condition and can fail intermittently.
But more importantly we are also setting up a BeforeStopRequestListener in the parent process, which gets notifications for ALL requests, but always with a size of 0 (because this is parent process and the information is normally not available there).
The issue is that the http-on-before-stop-request notification is always received in the parent process before we have time to communicate it from the content process. This means that at the moment, we always set ... 0, as the decoded body size.
The currently attached patch unexpectedly fixed this, by making the parent process listener ineffective. But by doing so, all tests about network continueWithAuth
with provideCredentials
start to timeout. It seems that the additional authentication attempts are only captured in the parent process here. Internally we skip the responseCompleted event for the intermediary attempts, and only emit an event for the last event, for which we can't get the decoded body size at the moment.
TLDR, the decoded body size handling is quite broken
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
Comment 4•2 months ago
|
||
Set release status flags based on info from the regressing bug 1882803
Updated•2 months ago
|
Assignee | ||
Updated•28 days ago
|
Updated•22 days ago
|
Description
•