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

Status: RESOLVED DUPLICATE of bug 1555057

(DevTools :: Netmonitor, enhancement, P3)

Description

[Julien Wajsberg [:julienw]]

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.

Comment 1

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

Thanks for the report Julien!

Honza

Comment 2

[:Harald Kirschner :digitarald]

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

Comment 3

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

Attachment: cors.patch

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

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

Honza

Comment 4

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

Attachment: Final patch?

Note for me, this might be the final patch
Honza

Comment 5

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

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

Comment 6

[Honza Bambas (:mayhemer)]

(Assuming no more info is required from me)