1377741 - Edit and resend doesn't work with filtered content

Status: RESOLVED DUPLICATE of bug 1340100

(DevTools :: Netmonitor, defect, P3)

Description

[Mitya]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

With developer tools open and the network console showing, I fired an AJAX request. It shows up. I edit the request and click 'resend'.


Actual results:

The request details pane disappears and no new request is sent (or at least it doesn't show in the network log to the left.)


Expected results:

Previously, a new request appeared in the list when you clicked 'resend'.

Comment 1

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

Is this report still valid?

Edit & Resend feature works for me.

Honza

Comment 2

[Mitya]

Yeap, same for me, and I recently updated to 55.0.3.

Literally the same deal as I originally described. When editing to resend, I press 'send', and the form closes and nothing happens - no new request fired.

Comment 3

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

Here is what I am doing:

0) Load http://janodvarko.cz/firebug/tests/601/Issue601.htm
1) Open DevTools Toolbox
2) Select the Network panel
3) Press the POST button on the page -> You should see a new request in the Network panel
4) Select the Request -> a side panel with request details should open
5) Select the Headers side panel (should be selected by default)
6) Click the "Edit and Resend" button
7) New request should appear in the Network panel and the content of the side panel should turn into a form
8) Click the "Send" button in the right top corner of the form
9) The entire side panel should disappear and there should be two requests in the Network panel

This works for me. Tested on Firefox 55 as well as 57 Nightly, Win10

If this doesn't work for you, what could be different in our configs?

Honza

Comment 4

[Mitya]

OK I think I've just realised what our difference is.

In the network panel I have the "XHR" tab highlighted, NOT "All"

I'm expecting re-sent requests to appear under XHR. This does not seem to be the case; they appear under All but for cause they have "JS other".

Is this intended? Have I imagined it that, previously, re-sent XHR requests appeared under the XHR tab?

Comment 5

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

I see, thanks for the update!

Yes, this should be fixed. Resent requests should have the same `cause` set.

I think this has been actually reported already. I'll keep this one open and we can mark it as dup if there is another version of the same issue reported.

Thanks!
Honza

Comment 6

[Mitya]

No problem - happy to help!

Comment 10

[piotr-yuxuan-github]

Just to friendly let you know it's still active. It's a bit disturbing first but it can easily be avoided when you also filter requests by "other".

Comment 11

[piotr-yuxuan-github]

In my humble opinion, here is the faulty test: https://github.com/mozilla/gecko-dev/blob/468205953d73fa5877e0e6c4264c55008a06631b/devtools/client/netmonitor/test/browser_net_resend.js#L163

However I'm unable to find where Actions are implemented and where action 'cloneSelectedRequest' is defined. Could somebody give me some feedback on this?

Comment 12

[:Harald Kirschner :digitarald]

Had the same issue, as filtering seems the first step to find a good resource to replay. The issue seems to be that the cloned request does not show up and therefore can't be edited; maybe filtering could ignore those entries until they are sent?

Comment 13

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

(In reply to piotr-yuxuan-github from comment #11)
> In my humble opinion, here is the faulty test:
> https://github.com/mozilla/gecko-dev/blob/
> 468205953d73fa5877e0e6c4264c55008a06631b/devtools/client/netmonitor/test/
> browser_net_resend.js#L163
> 
> However I'm unable to find where Actions are implemented and where action
> 'cloneSelectedRequest' is defined. Could somebody give me some feedback on
> this?

1) Here is the `CLONE_SELECTED_REQUEST` action reducer-handler:
https://searchfox.org/mozilla-central/rev/51268dcbdff0f6f4a5cff7986df0f616efc5bcfd/devtools/client/netmonitor/src/reducers/requests.js#121

Btw. `type` not cloned - see below.

2) Here is the action implementation:
https://searchfox.org/mozilla-central/rev/51268dcbdff0f6f4a5cff7986df0f616efc5bcfd/devtools/client/netmonitor/src/actions/requests.js#40

3) You might see (or use Browser Toolbox to inspect the UI of the Network panel) that the "Cause" column of the cloned request is set to `unknown`. This is why the filter doesn't work properly (hides the cloned request).

<div class="requests-list-column requests-list-cause" title="unknown">unknown</div>

Here is the place where it's set (look for the `type` field):
https://searchfox.org/mozilla-central/rev/51268dcbdff0f6f4a5cff7986df0f616efc5bcfd/devtools/client/netmonitor/src/components/RequestListColumnCause.js#41

4) After sending the request, the type is set to `others`, which is questionable and relates to the way how to request is triggered using the platform API.

Does that help?

Honza

Comment 15

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

One solution I am starting  to like is auto selecting the 'Other' filter when a request is resent.

Since setting 'other' cause type on resent requests might be actually the right way to go.

Honza

Comment 16

[meag.harty]

(In reply to Jan Honza Odvarko [:Honza] from comment #15)
> One solution I am starting  to like is auto selecting the 'Other' filter
> when a request is resent.
> 
> Since setting 'other' cause type on resent requests might be actually the
> right way to go.
> 
> Honza

Hey Honza,

I can take a look at this.

Thanks!
Meag

Comment 17

[Hengyeow (:tanhengyeow)]

Hi Meag

Are you still working on this? :)

Comment 18

[meag.harty]

(In reply to Heng Yeow (:tanhengyeow) from comment #17)
> Hi Meag
> 
> Are you still working on this? :)

Is this resolved by https://bugzilla.mozilla.org/show_bug.cgi?id=1340100 / your patch at https://phabricator.services.mozilla.com/D8126 since we now set the cause to the type of the original request (instead of Other)? If not, I will continue work on this.

Comment 19

[Hengyeow (:tanhengyeow)]

(In reply to meag.harty from comment #18)
> (In reply to Heng Yeow (:tanhengyeow) from comment #17)
> > Hi Meag
> > 
> > Are you still working on this? :)
> 
> Is this resolved by https://bugzilla.mozilla.org/show_bug.cgi?id=1340100 /
> your patch at https://phabricator.services.mozilla.com/D8126 since we now
> set the cause to the type of the original request (instead of Other)? If
> not, I will continue work on this.

Hi Meag

Yup I realized the patch fixes this issue too. It is currently awaiting approval to get landed :)

Comment 20

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

(In reply to Heng Yeow (:tanhengyeow) from comment #19)
> Yup I realized the patch fixes this issue too. It is currently awaiting
> approval to get landed :)

@Heng Please close this bug as duplicate as soon as bug 1340100 is resolved, thanks!
(or ping me if you can't do that for whatever reason)

Honza

Comment 21

[Hengyeow (:tanhengyeow)]

Hi :Honza 

Bug 1340100 is resolved. Seems like I can't close bugs not opened by me as duplicate. Would require your help on this :)

Comment 22

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

Thanks!

Honza