Closed Bug 1377741 Opened 3 years ago Closed 2 years ago
Edit and resend doesn't work with filtered content
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'.
Is this report still valid? Edit & Resend feature works for me. Honza
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.
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
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?
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
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Priority: P4 → P3
No problem - happy to help!
Duplicate of this bug: 1406863
Duplicate of this bug: 1449495
Duplicate of this bug: 1472640
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".
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?
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?
(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
Duplicate of this bug: 1481128
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
QA Contact: odvarko
(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
Hi Meag Are you still working on this? :)
(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.
Flags: needinfo?(meag.harty) → needinfo?(E0032242)
(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 :)
(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
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 :)
Flags: needinfo?(E0032242) → needinfo?(odvarko)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1340100
You need to log in before you can comment on or make changes to this bug.