1378464 - While requests are pending, "copy as curl" context menu doesn't work

Status: RESOLVED DUPLICATE of bug 1452442

(DevTools :: Netmonitor, defect, P3)

Description

[:Gijs (he/him)]

STR:

1. open network monitor
2. open a page that doesn't return data for a while
3. click the entry in the network monitor. Request headers are shown
4. right click the entry, choose 'copy as curl'
5. try to paste somewhere

ER:

paste curl commandline

AR:
clipboard contents haven't changed

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@stefan: I know you have been working on this feature in the past.
Any tips what could be wrong here?

Thanks!

Honza

Comment 2

[Stefan Yohansson]

@Honza as far I know the error is:
TypeError: selected.requestHeaders is undefined at devtools/client/netmonitor/src/request-list-context-menu.js

but I am unsure about what's causing it.

Comment 3

[Stefan Yohansson]

but I am unsure if it's the same STR reported, since I can't see Request headers on my pending request.

How can I reproduce it? I made a mock server that sleep for seconds while I copy as curl, but for this request there is no headers yet. (obviously) Headers panel displays: "No headers for this request"

Comment 4

[Stefan Yohansson]

Attachment: Screenshot_20170706_155844.png

Hi @Gijs

I can't understand the STR as well:

> 2. open a page that doesn't return data for a while

is it waiting for the response, right?

> 3. click the entry in the network monitor. Request headers are shown

on my network monitor, a request that don't receive a response won't show request headers.

You can see what I am receiving on attachment and understand what I've done reading comment #3.

Comment 5

[:Gijs (he/him)]

(In reply to Stefan Yohansson from comment #4)
> Created attachment 8884033 [details]
> Screenshot_20170706_155844.png
> 
> Hi @Gijs
> 
> I can't understand the STR as well:
> 
> > 2. open a page that doesn't return data for a while
> 
> is it waiting for the response, right?

I guess so. I saw this when google.com was misbehaving on my normal machine in private browsing mode (other sites were responsive, as was google in non-private-browsing windows). I can no longer reproduce this issue so I'm not 100% sure about what happened.

> > 3. click the entry in the network monitor. Request headers are shown
> 
> on my network monitor, a request that don't receive a response won't show
> request headers.

I don't know anything about when request headers show up. However, logically speaking, my understanding is that request headers would be sent once the tcp connection is established, and once that happens it's not necessary for there to be data / a response - the headers have been sent. So I would expect the request headers to be available.

Specifically, if you do this in the commandline:

cat | nc -l 8888

and then open a new tab, open the network monitor, and try to reach localhost:8888, the context menu in the network monitor doesn't show 'copy request headers' (leaving an odd double-separator with nothing in the middle...) but it does show 'copy as curl', except the entry doesn't work.

At a minimum, it should hide the other entries that don't work (like copy as curl) and ensure the separators don't look that dumb -- but actually, if you look at your commandline, you can see that nc has received request headers - so why isn't the network monitor showing them?

Comment 6

[Robert Xiao]

Probably fixed by https://hg.mozilla.org/mozilla-central/rev/0ed269252f57 (fix to Bug 1452442).

Comment 7

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Gijs: can you please confirm that this bug is fixed?

Thanks!
Honza

Comment 8

[:Gijs (he/him)]

Yes, this looks fixed to me.

Comment 10

[Tom Glowka]

Attachment: Fix generating curl commands with multipart payload

Fix main bug. Refine output of curl with multipart data payload.
Add missing units tests, including regression tests.

Comment 11

[Phabricator Automation]

Comment on attachment 9055361 [details]
Fix generating curl commands with multipart payload

Revision D25890 was moved to bug 1085481. Setting attachment 9055361 [details] to obsolete.