Closed Bug 1790370 Opened 2 years ago Closed 1 year ago

Implement "network.responseStarted" event

Categories

(Remote Protocol :: WebDriver BiDi, task, P1)

task
Points:
5

Tracking

(firefox110 fixed)

RESOLVED FIXED
110 Branch
Tracking Status
firefox110 --- fixed

People

(Reporter: whimboo, Assigned: jdescottes)

References

(Blocks 4 open bugs, )

Details

(Whiteboard: [webdriver:m5][wptsync upstream][webdriver:relnote])

Attachments

(3 files)

No description provided.
Type: enhancement → task

Let's discuss if we want to keep this in m5, it might be at risk

Whiteboard: [webdriver:m5] → [webdriver:m5][webdriver:triage]

Removing triage keyword, we are already discussing about when to end the milestone or not.

Whiteboard: [webdriver:m5][webdriver:triage] → [webdriver:m5]
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED

Hi Valentin,

Question about nsIChannel's protocolVersion. In our current CDP implementation this is what we use to retrieve the protocol used for a given response. I am checking if I could reuse this for our WebDriver BiDi implementation. The specification for the protocol we should expose in our network events is at https://pr-preview.s3.amazonaws.com/w3c/webdriver-bidi/pull/204.html#get-the-protocol , the most important part being:

If response’s final connection timing info is not null, set protocol to response’s final connection timing info's ALPN negotiated protocol.

Does this match nsIChannel protocolVersion? If yes, do you know when we can start reading this on the channel? If not, do you have any suggestion to get the correct value here?

Thanks!

Edit: I should have read the idl first :) it looks like this is pretty self explanatory:

/**
     * Returns the network protocol used to fetch the resource as identified
     * by the ALPN Protocol ID.
     *
     * @throws NS_ERROR_NOT_AVAILABLE if called before the response
     *         has been received (before onStartRequest).
     */
    [must_use] readonly attribute ACString protocolVersion;

but let me know if you have any concern around this nonetheless.

Flags: needinfo?(valentin.gosu)
Blocks: 1806794
Blocks: 1806799
Blocks: 1808560

(In reply to Julian Descottes [:jdescottes] from comment #3)

Does this match nsIChannel protocolVersion? If yes, do you know when we can start reading this on the channel? If not, do you have any suggestion to get the correct value here?

Yes, the timing protocolVersion is the same from nsIChannel.protocolVersion - we set it here

Note that for cached resources, we might report the protocol version used to get the original resource - which I believe is not spec compatible.

Flags: needinfo?(valentin.gosu)
Blocks: 1808688
Blocks: 1808937
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4cd27b33734e
[devtools] Expose transferredSize from devtools NetworkObserver r=devtools-reviewers,ochameau
https://hg.mozilla.org/integration/autoland/rev/ba47533a1f81
[bidi] Add basic support for network.responseStarted event r=webdriver-reviewers,Sasha,whimboo
https://hg.mozilla.org/integration/autoland/rev/abe601ec2aa5
[wdspec] Add tests for network responseStarted r=webdriver-reviewers,whimboo
Failed to create upstream wpt PR due to merge conflicts. This requires fixup from a wpt sync admin.
Whiteboard: [webdriver:m5] → [webdriver:m5], [wptsync upstream error]
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/37803 for changes under testing/web-platform/tests
Whiteboard: [webdriver:m5], [wptsync upstream error] → [webdriver:m5], [wptsync upstream]
Upstream PR merged by jgraham
Whiteboard: [webdriver:m5], [wptsync upstream] → [webdriver:m5][wptsync upstream][webdriver:relnote]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: