Open Bug 1809210 Opened 1 year ago Updated 1 year ago

Emit network.responseCompleted at the expected time for redirected requests

Categories

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

defect
Points:
2

Tracking

(Not tracked)

People

(Reporter: jdescottes, Unassigned)

References

Details

(Whiteboard: [webdriver:backlog])

Tentatively filing this as a follow up for Bug 1790372.
With the current implementation, for a redirect, assuming requestA redirects into requestB, responseCompleted for requestA is emitted after beforeRequestSent is received for requestB.

This fails the assert from the spec about the before request sent map, meaning we should have fully processed requestA before emitting events for requestB.

Check with necko team if the current event order makes sense, maybe we need a spec update.

Severity: -- → S3
Points: --- → 2
Flags: needinfo?(jdescottes)
Priority: -- → P2
Whiteboard: [webdriver:m6]
Flags: needinfo?(jdescottes)
Whiteboard: [webdriver:m6] → [webdriver:backlog]

Resetting the unexpectedly removed needinfo request for Julian.

Flags: needinfo?(jdescottes)

With the current implementation, for a redirect, assuming requestA redirects into requestB, responseCompleted for requestA is emitted after beforeRequestSent is received for requestB.

I think this makes sense.
We process the response for requestA, look at the header and issue requestB.
Then the body of requestA is delivered, but we ignore it.

Could you point me to the BiDi spec text?
Thanks!

Thanks Valentin!

The BiDi spec for network events has not landed yet, but the current version is visible at https://pr-preview.s3.amazonaws.com/w3c/webdriver-bidi/pull/204.html#event-network-responseCompleted. :jgraham is open to change the ordering here.

Especially this version contains assertions based on a before request sent map which assume that all events for request A have been fully processed before we process any event for request B.

We process the response for requestA, look at the header and issue requestB.
Then the body of requestA is delivered, but we ignore it.

I should track exactly how we detect the end of the response for requestA but given what you are saying here, we might just detect that the stream gets closed at some point and that's why we get the event so late. If we ignore the response body for requestA, I'm wondering if on BiDi side it would make sense to emit responseCompleted right after responseStarted when we see that this is going to be a redirect.

Flags: needinfo?(jdescottes)

I'm wondering if on BiDi side it would make sense to emit responseCompleted right after responseStarted when we see that this is going to be a redirect.

It really depends on what we want to surface through BiDi - the body of the redirect isn't really normally used for anything, so I can see both orders of events being correct, depending on how you look at it.

You need to log in before you can comment on or make changes to this bug.