Closed Bug 1931334 Opened 1 year ago Closed 1 year 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 wontfix, firefox136 wontfix, firefox137 wontfix, firefox138 fixed)

RESOLVED FIXED
138 Branch
Tracking Status
firefox-esr128 --- unaffected
firefox132 --- wontfix
firefox133 --- wontfix
firefox134 --- wontfix
firefox135 --- wontfix
firefox136 --- wontfix
firefox137 --- wontfix
firefox138 --- fixed

People

(Reporter: jdescottes, Assigned: jdescottes)

References

(Regressed 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [webdriver:m15], [wptsync upstream])

Attachments

(4 files, 1 obsolete 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
Attachment #9468249 - Attachment description: Bug 1931334 - Stop listening for beforeRequestStop in the root module → Bug 1931334 - [bidi] Fix race condition in NetworkDecodedBodySizeMap
Attachment #9437728 - Attachment is obsolete: true
Attachment #9468252 - Attachment description: Bug 1931334 - Stop listening for beforeRequestStop in the root module → Bug 1931334 - [bidi] Stop listening for beforeRequestStop in the root module

Depends on D239499

Waiting for the decoded body size in content processes introduces a slight delay
which impacts cached response completed tests.

Attachment #9471176 - Attachment description: Bug 1931334 - [wdspect] Relax BiDi network tests for cached requests → Bug 1931334 - [wdspec] Relax BiDi network tests for cached requests

Depends on D241086

Adds a simple test for the content size of gzipped network response.
This test only asserts that the value is non-zero. At the moment Chrome seems to
always return 0. Once other implementations than Firefox return something else than
0 we can update the assertion to assert the actual size.

Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/be6aafb658cc [bidi] Fix race condition in NetworkDecodedBodySizeMap r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/e8bc2a74f3e8 [bidi] Stop listening for beforeRequestStop in the root module r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/e22041831189 [wdspec] Relax BiDi network tests for cached requests r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/09dd3cea930e [wdspec] Add wdspec tests for network.responseCompleted content.size r=webdriver-reviewers,whimboo
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/51580 for changes under testing/web-platform/tests
Whiteboard: [webdriver:m15] → [webdriver:m15], [wptsync upstream]
Regressions: 1956322
No longer regressions: 1956322
Upstream PR merged by moz-wptsync-bot
Regressions: 1957050
Regressions: 1959614
Regressions: 1959621
Whiteboard: [webdriver:m15], [wptsync upstream] → [webdriver:m15], [wptsync upstream][webdriver:relnote]
Whiteboard: [webdriver:m15], [wptsync upstream][webdriver:relnote] → [webdriver:m15], [wptsync upstream]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: