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

RESOLVED DUPLICATE of bug 1340100

Status

defect
P3
normal
RESOLVED DUPLICATE of bug 1340100
a year ago
4 months ago

People

(Reporter: ardeshireo, Unassigned)

Tracking

(Blocks 1 bug)

59 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

User Story

See comment #12 for detailed STR

Attachments

(1 attachment)

Reporter

Description

a year ago
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

Updated

a year ago
Component: Untriaged → Developer Tools: Netmonitor

Comment 1

a year ago
I can reproduce here. 

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

Comment 2

a year ago
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.
Reporter

Comment 3

a year ago
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

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

Comment 6

a year ago
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

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

Comment 8

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

Comment 9

a year ago
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

a year ago
(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

a year ago
Bug also still exist in Nightly 61.0a1 and Dev 60.0b15 on Windows 10
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
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
User Story: (updated)
Reporter

Comment 13

a year ago
@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

a year ago
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

a year ago
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

a year ago
(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

a year ago
(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 19

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

Comment 20

a year ago
(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

a year ago
(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!
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

a year ago
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).

Updated

11 months ago
Product: Firefox → DevTools

Comment 24

11 months ago
(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

11 months ago
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

11 months ago
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

10 months ago
I have the same issue. Only works on "All". Please fix.
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.
Flags: needinfo?(odvarko)

Comment 29

8 months ago
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.
(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
Flags: needinfo?(odvarko)
Hi :Honza

The patch for Bug 1340100 should fix this issue. Require your confirmation on this :)
Flags: needinfo?(odvarko)

Comment 32

7 months ago
(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!
(In reply to Igor from comment #32)
> Now it works in my case. Thank you!
Thanks for the confirmation!

Honza
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Flags: needinfo?(odvarko)
Resolution: --- → DUPLICATE
Duplicate of bug: 1340100
Reporter

Comment 34

4 months ago

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

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

You need to log in before you can comment on or make changes to this bug.