User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

I send post request to a slow server

Actual results:

I can not see POSTed data

Expected results:

I should see POSTed data immediately after request is sent

Can you provide clear and simple steps to reproduce? I need to reproduce the issue myself in order to confirm it. Thank you!

just send request to server which responds after 30s for example.
Thus you have time to notice that posted data is not visible at dev.tools

I have attempted to reproduce the issue using the following steps:

1. Took this server from: http://biercoff.com/simple-http-server-that-will-give-serve-simple-files-and-can-emulate-delay-before-giving-response/
2. Modified the code to delay the server response with 15-30-60 seconds.
3. Ran it with Python 2.
4. Opened a page from the server with Firefox and navigated around the local server.
   -> Could not reproduce the behavior seen in the video attached, could not see the "Params" section of the post event being populated at all.
   I do not have the necessary technical knowledge to reproduce that. I had to take quite some time to do "trial and error" until I reproduced this much. Please help me further. Thanks.

I create the server with 7sec timeout. Try: http://193.151.89.164:8080/ff

Here is the demo for URL above

I can confirm this issue using the server link in comment 4. It occurs on Nighty v69.0a1 (2019-07-01), Beta v68.0b14 and Release v67.0.4.
I am setting component to (Core) Networking.
Reporter: Thank you for help. the server could be closed if it troubles in any way, but I will need it working again if the bug gets fixed. Thanks!

would be nice if it will be fixes ASAP, because, probably, I will do not remember details later. or have no access to server etc.
I have already such reports where after a year or so I was asked additional info.
I am glad to help, but memory, resources etc =(

And thank you to confirm it +1

Awesome. You could share the server code here and I will have it when verification is needed. Thanks!

something like this:

sub ff_post {
sleep 7;
shift->render( 'response text is here' );
}

I am not familiar with devtool/netmonitor code.

Honza, could you take a look? Thanks.

Thanks for the report.

Analysis

STR:

1. Load http://193.151.89.164:8080/ff
2. Press the button on the page
3. See new entry/request in the panel content
4. Select the Request and see the Params panel
5. Post data are available when the request finishes -> BUG
   Expected: post data can be visible in the Params panel since the requests is sent.

• The back-end is collecting the POST data here:
  https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/devtools/server/actors/network-monitor/network-observer.js#491

It sends a notification about the POST data being available to the client/Network panel immediately

• The Network panel handles the notification/update events here:
  https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/devtools/client/netmonitor/src/connector/firefox-data-provider.js#390

• The update event (informing the Network panel that POST data body is available) is stored in a queue
  https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/devtools/client/netmonitor/src/connector/firefox-data-provider.js#433

Important is that the ${updateType}Available flag is stored in the queue - indicating that specific data/updateType (like e.g. requestPostData) are available on the backend for pickup (the data itself needs to be fetched explicitly).

The Params panel does request the requestPostData explicitly here (when the panel is created):
https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/devtools/client/netmonitor/src/components/ParamsPanel.js#67

using fetchNetworkUpdatePacket util function

• The fetchNetworkUpdatePacket is implemented here:
  https://searchfox.org/mozilla-central/rev/15be167a5b436b57fef944b84eef061d24c1af8c/devtools/client/netmonitor/src/utils/request-utils.js#91

And it only fetches the data if request[${updateType}Available] == true, which isn't => BUG

This means that we set the flag (about request post data being available) in the FirefoxDataProvider, but it isn't propagated to Requests reducer and thus fetchNetworkUpdatePacket has no effect.

Honza

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

As the previous test case links don't work anymore, here is a new one (GET request):
http://www.mocky.io/v2/5e84bfbb300000bd0597abe8?mocky-delay=10000ms

If that link breaks after some time, a new request can easily be created from the homepage of Mocky again.

Note that this affects all request methods, not only POSTs. What should be available at the time of the request are at least headers and payload information, parameters (already shown), the call stack (probably already shown, not possible to test with Mocky and can't test it locally right now), and partially the timings.

Sebastian

This also makes SSE debugging feel really awkward, as most tabs stay empty while data is coming in.

I would love for this to be resolved. Was sharing my screen the other day working through a thing, and my coworker mentioned that you can see the request right away in Chrome, where as I expected this was just normal behavior in all browsers.

No real details needed I'd think, it's simply that working in FF devtools, having your webapp fire an XHR request, you do not see anything in the Request/Headers tab until the request finishes.