1432724 - Developer Tools -> Network -> Request -> Edit and Resend closes the request

Status: RESOLVED DUPLICATE of bug 1340100

(DevTools :: Netmonitor, defect, P3)

Description

[Ardeshir Izadi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180122144853

Steps to reproduce:

HI! I'm on aurora update channel and I just updated to v59.b03 (64bit);
In my Developer Tools -> Network -> Request -> when I click on Edit and Resend, The Request pane closes and returns back to requests list

Comment 1

[Casper Braschi]

Attachment: Request pane closing after hitting "Edit and Resend".

I can reproduce here. 

Firefox Dev Edition 59.0b5 (64-bit) 
Ubuntu 16.04 machine

Comment 2

[david]

I also have this issue on Windows 10 1703 in Nightly 60.0a1 (2018-02-07) (64-bit) and Dev Edition 59.0b7 (64-bit).

Along with with the pane closing issue on the above Nightly and Dev edition --data is empty even when there should be data in the Copy as cURL feature.

Stable 58.0.1 (64-bit) does not have either issue.

Comment 3

[Ardeshir Izadi]

a note:
For me this happens only I have filtered XHR requests.
When the filter mode is on 'All', it seems to be working

Comment 4

[Maxim Nosovets]

I'm confirm bug - https://i.imgur.com/gdYvCLw.gifv
Reproducible in Firefox Developer Edition 59.0b10

Comment 6

[coastermcgee]

I'm having the same issue on both an up to date Nightly and on 59.0.2.  Edit and Resend works if I have "All" selected in the network tab, but having only "XHR" selected causes the issue to appear.

Comment 7

[Ryan Hayle]

Just confirming that this is still an issue on 60.0b9.  Could someone at least mark this as confirmed?

Comment 8

[Igor]

Bug isn't relevant in Developer Edition v60.0b10, but for some reason still presents in Nightly v61.0a1

Comment 9

[josh]

Bug is relevant and reproducible with FireFox Developer Edition V60.0b11 (64-bit) on macOS High Sierra 10.13.3. Check this screen vid for details: https://drive.google.com/open?id=186TFPtckz69xxje5MKdPEo6Er68ldh5c.

Comment 10

[Lucas]

(In reply to coastermcgee from comment #6)
> I'm having the same issue on both an up to date Nightly and on 59.0.2.  Edit
> and Resend works if I have "All" selected in the network tab, but having
> only "XHR" selected causes the issue to appear.

Thanks @coastermcgee ! Remove XHR filter works for me. Since the new request is as "Unknown" ("Other" in the filters) it isn't allowed to edit if any other filter is set.

Comment 11

[Igor]

Bug also still exist in Nightly 61.0a1 and Dev 60.0b15 on Windows 10

Comment 12

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

I can't reproduce the problem in Firefox 61

My STR:
1) Load this page http://janodvarko.cz/firebug/tests/601/Issue601.htm
2) Open the DevTools Toolbox and select the Network panel
3) Click on the POST button on the page to generate XHR request
4) Click on the XHR filter button in the toolbar
5) Select the POST request in the panel (the side bar should open), select Headers
6) Click the "Edit and Resend" button in the side bar, the side bar closes -> BUG

The new request has been actually generated, but since it has different type (not XHR) it isn't visible because of the filter.

Honza

Comment 13

[Ardeshir Izadi]

@Honza That's strange!! very strange!

It worked for me too.

But almost in every other page it doesn't work. and its not just XHR.
if you have selected any type of filter (HTML, JS, XHR, etc...) on clicking `Edit and Resend` the pane closes. (Except that lats one (`Other`) which has a worse behavior and is always in `Edit & Resend` mode;

- for example try these:
--- search something in google and inspect requests
--- inspect requests in this page : https://bugzilla.mozilla.org/show_bug.cgi?id=1432724
--- inspect requests on this: https://www.mozilla.org/en-US/firefox/new/

I confirm that `Edit and Resend` works on that particular link you sent. (http://janodvarko.cz/firebug/tests/601/Issue601.htm)

But in (almost) every other page, my `Edit & Resend` is not working. (in filter mode/XHR mode)
I'm on Firefox 61.b02. Firefox Developer Edition

: )

Comment 14

[michal.masek]

So the problem is, that when you click "Edit and resend" the new request is marked as "unknown" and not XHR so it is not visible in the XHR filter anymore.

I think the fix would be if the "cause" of the new request is copied from the original request. Now the cause of the new request is "unknown"

Comment 15

[Igor]

Firefox Dev 61.0b4 (64-bit) "Edit and resend" works only for "Fonts" and "Other". For other types it's just closing the panel. Happening for any website.

Comment 16

[Maxim Nosovets]

(In reply to Igor from comment #15)
> Firefox Dev 61.0b4 (64-bit) "Edit and resend" works only for "Fonts" and
> "Other". For other types it's just closing the panel. Happening for any
> website.

Can't reproduce - https://de-v.net/v/2018-05-15_10-12-03.mp4

Comment 17

[Igor]

(In reply to Maxim Nosovets from comment #16)
> (In reply to Igor from comment #15)
> > Firefox Dev 61.0b4 (64-bit) "Edit and resend" works only for "Fonts" and
> > "Other". For other types it's just closing the panel. Happening for any
> > website.
> 
> Can't reproduce - https://de-v.net/v/2018-05-15_10-12-03.mp4

Hi, thank you for your time spending on this issue. This is a big problem for me because I use this function quite a lot and for now just forced to use another browser.

Here is the video of what happening on my side: https://1drv.ms/v/s!AlqPFN8unomDoVEpkbGMU9LTDSI- 

P.S. The context menu with the option like you did in your video was not fully displayed in my video recorder, but you can see an alternate method by click on the button "Edit & Resend".

Comment 18

[Igor]

https://1drv.ms/v/s!AlqPFN8unomDoVEpkbGMU9LTDSI-

Comment 19

[Igor]

Please copy the link with the dash in the end. The forum cut it down at the end for some reason.

Comment 20

[michal.masek]

(In reply to Igor from comment #19)
> Please copy the link with the dash in the end. The forum cut it down at the
> end for some reason.

Like it was mentioned already: a new request is successfuly created. If you switch to the "All" tab you'll see it. You just can't see it under the filters (CSS/JS/XHR/...) because this new request is not marked as CSS/JS/XHR but just "unknown"

Comment 21

[Igor]

(In reply to michal.masek from comment #20)
> (In reply to Igor from comment #19)
> > Please copy the link with the dash in the end. The forum cut it down at the
> > end for some reason.
> 
> Like it was mentioned already: a new request is successfuly created. If you
> switch to the "All" tab you'll see it. You just can't see it under the
> filters (CSS/JS/XHR/...) because this new request is not marked as
> CSS/JS/XHR but just "unknown"

Oh, indeed, it works in the "All" tab. I'm glad that there is a solution to use this functionality, but bug is still present, so please fix it in the future versions.

Anyway, thank you for help!

Comment 22

[Alexander Rotnov]

Here is a steps to reproduce problem in 1446381 (closed as duplicate)
1. Open new tab.
2. Open Developer Tools (F12), select Network tab.
3. Go to resource, that return application/json content(for example ip.jsontest.com).
4. Hit Reload on Network tab.
5. Select incoming request.
6. Hit Edit and Resend and hit Send - nothing happens.
8. Close Dev Tools.
9. Try to open Dev Tools again by hitting F12 - nothing happens.

Maybe there is something wrong with json viewer.

Comment 23

[ngocthinhdp]

http://jmp.sh/EEa4HAV

In Network tab, turn on XHR & Other tab at the same time, your problem will be resolved. Btw, in my opinion, it is not good(about UX).

Comment 24

[Daniel Moore]

(In reply to michal.masek from comment #20)
> (In reply to Igor from comment #19)
> > Please copy the link with the dash in the end. The forum cut it down at the
> > end for some reason.
> 
> Like it was mentioned already: a new request is successfuly created. If you
> switch to the "All" tab you'll see it. You just can't see it under the
> filters (CSS/JS/XHR/...) because this new request is not marked as
> CSS/JS/XHR but just "unknown"

I am also seeing this. FF release channel, macOS, 60.0.2 (64-bit)

Comment 25

[jaimeburnap]

I also have this problem with 61.0b12. I can confirm switching to the "All" filter allows me to finished sending the headers. It is categorized as "other" after it finished.

Windows 10. 64-bit Firefox Developer Edition.

Comment 26

[Stanislav Fedorov]

I have this problem too. On "All" tab "Edit and resend" works, on other tabs - close request data window. Ubuntu 16.04, Firefox 61 64bit.

Comment 27

[olga.maciaszek]

I have the same issue. Only works on "All". Please fix.

Comment 28

[Merike Sell (:merike)]

Seems to be related to bug 1227746 after which edit panel is closed automatically because the request itself isn't listed and visible due to type filter mismatch. As I got lost in devtools code anyway while tracking it down, two questions:

1. What should the expected behaviour here be? Should custom requests be listed in all filters by default? Should they have initial type set based on previous request? Something else?
2. If listing these in all filters is acceptable is it just about changing https://dxr.mozilla.org/mozilla-central/source/devtools/client/netmonitor/src/selectors/requests.js#44 to
return (matchesType || r.isCustom) && isFreetextMatch(r, filters.requestFilterText); ? The latter changes the behaviour to what I would expect to see and does not seem to break any existing netmonitor tests.

Comment 29

[Hugh]

Still a bug in FF Developer 63.0b6.

I think that if you edit and resend an XHR request, it should be classified as XHR and show up on that filter. Ideally, it would have some special marker, e.g. "xhr (edited)".

Alternatively, the initial "unknown" request type should bypass filters, and the "other" filter should get added to the current filter so that the sent request shows up.

Comment 30

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

(In reply to Merike Sell (:merike) from comment #28)
> Seems to be related to bug 1227746 after which edit panel is closed
> automatically because the request itself isn't listed and visible due to
> type filter mismatch. As I got lost in devtools code anyway while tracking
> it down, two questions:
> 
> 1. What should the expected behaviour here be? Should custom requests be
> listed in all filters by default?
Yes, I think so.

> 2. If listing these in all filters is acceptable is it just about changing
> https://dxr.mozilla.org/mozilla-central/source/devtools/client/netmonitor/
> src/selectors/requests.js#44 to
Precisely!

Please see bug Bug 1492730, it has slightly different STRs, but
it's basically the same problem. I just provided detailed instructions
for anyone interested in fixing it. You might look at that.

Honza

Comment 31

[Hengyeow (:tanhengyeow)]

Hi :Honza

The patch for Bug 1340100 should fix this issue. Require your confirmation on this :)

Comment 32

[Igor]

(In reply to Heng Yeow (:tanhengyeow) from comment #31)
> Hi :Honza
> 
> The patch for Bug 1340100 should fix this issue. Require your confirmation
> on this :)

Now it works in my case. Thank you!

Comment 33

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

(In reply to Igor from comment #32)
> Now it works in my case. Thank you!
Thanks for the confirmation!

Honza

Comment 34

[Ardeshir Izadi]

I confirm it works on Windows 10: 65.0b10 (64-bit)

Thanks! I am seriously happy when I saw this behavior today : )