Open Bug 1931334 Opened 3 months ago Updated 22 days ago

Network event content.size is always set to 0

Categories

(Remote Protocol :: WebDriver BiDi, defect, P2)

defect
Points:
3

Tracking

(firefox-esr128 unaffected, firefox132 wontfix, firefox133 wontfix, firefox134 wontfix, firefox135 fix-optional)

ASSIGNED
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/

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.

Assignee: nobody → jdescottes
Status: NEW → ASSIGNED

Set release status flags based on info from the regressing bug 1882803

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

Points: --- → 3
Priority: -- → P2
Whiteboard: [webdriver:m15]
Severity: -- → S3

Set release status flags based on info from the regressing bug 1882803

Summary: Unnecessary IPC and log pollution due to network._beforeStopRequest events → Network event content.size is always set to 0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: