1883380 - XHRs manually resent via Devtools > Network don't show response

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect, P2)

Description

[Mitya]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0

Steps to reproduce:

1. Go to any webpage that fires an XHR
2. Open dev tooks > network
3. Cause the XHR to fire
4. Highlight the XHR in the list of requests
5. Right click, click either "resend" or "edit and resend" then "send"

Actual results:

The request is resent but the response is hidden, i.e. under the "Response" tab there's nothing (but for the original XHR, fired by the web page itself, the response is shown.) See attached video.

Expected results:

Response to be shown.

Comment 1

[Mitya]

For whatever reason the video file I tried to attach didn't attach (though no feedback/error was given). Here it is: https://mitya.uk/firefox-issue.asf

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Netmonitor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

Hello Mitya, we can't reproduce the issue easily, so maybe there's something specific about those requests that triggers the problem.
Would you be able to share the page you're seeing this on?
If not, can you tell us how the request is made, does it have credentials, is it done on a different domain than the page itself, …

Thanks!

Comment 4

[Mitya]

For me this happens on all sites and with all requests. I've disabled ad-blocker, in case that was it, but no difference.

Example: https://ecosia.org. If you open that URL with the network console open, you should see an XHR with a URI containing notifications?. That has a JSON response. If I right click and refire it, it sends the request, and it completes again with a 200, but the response tab says "No response data available for this request".

Comment 5

[Julian Descottes [:jdescottes]]

Thanks for the additional details, we can reproduce with this website. It seems that the resent request is using slightly different headers compared to the original one (eg Sec-Fetch-Mode is set to no-cors instead of cors)

Comment 6

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1883380 - [devtools] Set the correct security context for the resent request based on the original request r=#devtools

Comment 7

[Mitya]

Interesting. So should this be configured a bug? Surely "resend" should resend the request exactly "as was", same headers, same everything. Or did you mean the server is giving different headers in its response to the re-sent request?

Comment 9

[Julian Descottes [:jdescottes]]

Hi Bomsy, not sure if you have seen the feedback from Valentin and Nicolas on the patch, could we make this move forward?

Comment 10

[Hubert Boma Manilla (:bomsy)]

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

Hi Bomsy, not sure if you have seen the feedback from Valentin and Nicolas on the patch, could we make this move forward?

Apologies, got back to this.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3925e3794bb3
[devtools] Set the correct security context for the resent request based on the original request  r=valentin,devtools-reviewers,nchevobbe

Comment 12

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/3925e3794bb3