New issue
Advanced search Search tips

Issue 806866 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Nov 17
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Redirected XHR / Fetch requests are not filtered as XHR/fetch requests in Devtools

Reported by linus....@spensatech.com, Jan 29 2018

Issue description

Chrome Version       : 66.0.3329.1 (also reproduced on stable - 63.0.3239.132)
OS Version: OS X 10.13.2
URLs (if applicable) : N/A, test case as a node.js server attached.
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari: OK
    Firefox: OK
    IE/Edge: N/A, not tested on Windows.

What steps will reproduce the problem?
1. Navigate to a page that makes an XHR or Fetch request to a 301 or 302 redirect. The redirected (final) URI should return a proper XHR response. In my case, I tested with a short node.js script attached below as a server, and loaded up localhost:8080.
2. Refresh the page with the devtools network panel open. One expects the final response (with valid data) to be logged as an XHR item and filtered under "XHR" (as in Safari, attached) or perhaps both the redirected and the final request to be filed under XHR (as in Firefox, attached). But Chrome puts both of them under the ambiguous "Other" category, which while heuristically may make sense, ultimately gets in the way of normal development workflow where one expects to find all XHR requests and responses under XHR, regardless of redirects.

* This seems like it could be somewhat of a subjective issue -- is a redirect-initiated request really an XHR? Is a redirect-response to a fetch really an XHR? From a web dev's point of view, it's inconvenient to have to remember to use a different filter for potentially redirected requests, and I find Firefox's behavior of logging both requests under XHR most sensible.

What is the expected result?
As the developer, I expect to find all my XHR requests, even redirected ones, under the XHR filter.

What happens instead of that?
The fetch request was filtered as an "Other" request.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3329.1 Safari/537.36



 
chrome-xhr.png
115 KB View Download
chrome-other.png
127 KB View Download
safari.png
99 KB View Download
firefox.png
39.0 KB View Download
test.js
1.6 KB View Download
Labels: Needs-Triage-M66
Components: Platform>DevTools

Comment 3 by l...@chromium.org, Jan 31 2018

Owner: eostroukhov@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks so much for the screenshots and repro case.  Sounds reasonable to me if other platforms treat those as XHR.
console
14 bytes View Download
Owner: jarhar@chromium.org
Status: Fixed (was: Assigned)
I fixed this in a recent change:
https://chromium-review.googlesource.com/c/chromium/src/+/1219990

I used the provided test.js to reproduce in Canary and observed that the final fetch response after the redirect showed up as a "fetch" type.

linus.lee@ can you verify that this is fixed in Canary? The fix is not in stable chrome yet.
(I used to own linus.lee@ but switched workplaces.)

Thank you for the fix! I can verify that the fix works on most recent Canary.
Status: Verified (was: Fixed)

Sign in to add a comment