Tooltip for 'XHR' filter incorrectly says that it covers Fetch
Reported by
r...@designmynight.com,
Aug 24
|
|||
Issue descriptionChrome Version : 68.0.3440.106 (Official Build) (64-bit) What steps will reproduce the problem? Open the developer tools network tab and hover over the 'XHR' filter What is the expected result? The tooltip shouldn't include fetch What happens instead? The tooltip says 'XHR and Fetch' Please provide any additional information below. Attach a screenshot if possible. In the developer tools 'Network' tab the network requests can be filtered. The 'XHR' tab has a tooltip which says 'XHR and Fetch' but Fetch requests don't appear under this filter. Requests using the ES6 fetch API appear under the 'other' filter. Either the tooltip is wrong or the filter is wrong. However, because fetch doesn't use XHR I would expect it to either appear under 'other' or under a different 'fetch' filter.
,
Aug 25
,
Sep 7
,
Sep 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/548eb56296ec9a1443f925a08c0cd092e7dc06bb commit 548eb56296ec9a1443f925a08c0cd092e7dc06bb Author: Joey Arhar <jarhar@chromium.org> Date: Fri Sep 14 22:05:55 2018 [DevTools] Fix redirected fetches appearing as Other in network tab Bug: 877519 Change-Id: I738d6f7f871413e2df493bc7918538be441464e0 Reviewed-on: https://chromium-review.googlesource.com/1219990 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#591491} [add] https://crrev.com/548eb56296ec9a1443f925a08c0cd092e7dc06bb/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/redirect-resource-type-expected.txt [add] https://crrev.com/548eb56296ec9a1443f925a08c0cd092e7dc06bb/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/redirect-resource-type.js [modify] https://crrev.com/548eb56296ec9a1443f925a08c0cd092e7dc06bb/third_party/blink/renderer/core/fetch/fetch_manager.cc [modify] https://crrev.com/548eb56296ec9a1443f925a08c0cd092e7dc06bb/third_party/blink/renderer/core/inspector/inspector_network_agent.cc [modify] https://crrev.com/548eb56296ec9a1443f925a08c0cd092e7dc06bb/third_party/blink/renderer/core/inspector/inspector_network_agent.h [modify] https://crrev.com/548eb56296ec9a1443f925a08c0cd092e7dc06bb/third_party/blink/renderer/core/probe/CoreProbes.json5 [modify] https://crrev.com/548eb56296ec9a1443f925a08c0cd092e7dc06bb/third_party/blink/renderer/core/probe/CoreProbes.pidl
,
Sep 19
When trying to reproduce this bug, I found that fetches actually do correctly get filtered in by the XHR filter. However, I found that in the case where the fetch gets redirected, both the original and the redirected requests in the Network panel don't get recognized as a fetch. example: fetch('https://en.wikipedia.org/wiki/google.com') redirects to fetch('https://en.wikipedia.org/wiki/Google.com').
I fixed this so that the redirected request appears as a fetch and will go into the XHR filter, which is the same thing XHRs do. Please reply with more specific steps to reproduce if you are still able to reproduce the bug on your system without a redirect.
,
Sep 25
Sorry, I realise now the important bit was that these were cross-origin requests. In this case the initial OPTIONS request appears under the XHR filter however the subsequent GET/POST request appears under the 'Other' filter.
,
Sep 25
I see, I was able to reproduce the bug with a cross-origin request in 69.0.3497.100. When trying to reproduce it in a development build with the fix I made for redirected fetches applied, both the OPTIONS and subsequent requests appeared as 'fetch' and showed up under the XHR filter, so I think my fix works for your case as well. The fix should be in canary by now if you want to test it out, or else I think it should be released in version 71. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dtapu...@chromium.org
, Aug 24