Closed Bug 1445637 Opened 6 years ago Closed 4 years ago

Requests rejected by CORS don't display properly in Network panel

Categories

(DevTools :: Netmonitor, enhancement, P3)

Product:
DevTools
Component:
Netmonitor
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1555057

People

(Reporter: julienw, Assigned: Honza)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

cors.patch
2.78 KB, patch
Details | Diff | Splinter Review
Final patch?
3.17 KB, patch
Details | Diff | Splinter Review 
Currently it's very difficult to debug what's happening when a fetch request is rejected because of CORS.

In the Netmonitor view, everything happens as if there was no error, we have properly a "200" status code and we can inspect the request. We should add an indicator when the fetch was then rejected by the browser because of CORS.
Thanks for the report Julien!

Honza
Priority: -- → P3
Product: Firefox → DevTools

We'll continue the investigation from bug 1556451 on CORS here.

Summary: Show when a request has been rejected because of CORS → Requests rejected by CORS don't display properly in Network panel
Attached patch cors.patch — — Splinter Review

Some analysis related to the following test case:

STR:
0) Apply the attached patch to see some logs in the Browser Console

  1. Open DevTools and select the Network panel
  2. Open the Browser Console
  3. Load https://firefox-devtools-blocked-resources.glitch.me/
  4. Check out the Browser Console.

The logs are only related to the following requests

  • bar.com
  • connect.facebook.net

You should see something as follows:

_httpStopRequest 2009, https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v3.0, 91173565759518 2 network-observer.js:326:15
_httpStopRequest 2009, https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v3.0, 91173565759523 network-observer.js:326:15
_httpStopRequest 2009, https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v3.0, 91173565759523 network-observer.js:326:15
_onTransactionClose https://bar.com/data.json, 91173565759520 2 network-observer.js:1063:15
_httpResponseExaminer 0, https://bar.com/data.json, 91173565759520 2 network-observer.js:378:15
_httpStopRequest 1005, https://bar.com/data.json, 91173565759520 2 network-observer.js:326:15

@mayhemer: two questions:

  1. How come there are "http-on-stop-request" and "http-on-examine-response" send after ACTIVITY_SUBTYPE_TRANSACTION_CLOSE is that expected? Is there any event that is always sent as the last one so, we know that the channel is definitely closed?

This is also related to my question in bug 1555057 comment #61

  1. How come there are two _httpStopRequest for one channel connect.facebook.net, is that expected?

Honza

Assignee: nobody → odvarko
Flags: needinfo?(honzab.moz)
Attached patch Final patch? — — Splinter Review

Note for me, this might be the final patch
Honza

Attachment #9146089 - Attachment is patch: true

This should be fixed by patch in bug 1555057
Closing as dup
Honza

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

(Assuming no more info is required from me)

Flags: needinfo?(honzab.moz)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: