We've landed 1157817 which was meant to display blocked resources in the Network Panel. URLS blocked by CSP currently display via the 1157817 patch, supported by unit test, but requests CORS errors and tracking URLs either don't make it to the Network Panel or display in the network panel as loaded properly/200.

Easy STR for a tracking URL:

1. Go to Reddit homepage
2. In the console you will see that "https://rules.quantcount.com/rules-p-xLEyC0FLYFXAH.js" was blocked for tracking
3. Check network monitor
4. https://rules.quantcount.com/rules-p-xLEyC0FLYFXAH.js displays as a 200/cached file

If the file was actually blocked for tracking, the request should have triggered a "http-on-failed-opening-request" or similar event to let devtools/server/actors/network-monitor/network-observer.js know that the request had been blocked, with a blockeReason, so that we could display that information to the user.

Test site which blocks a set of resources based on CORS, CSP, Mixed content and url classification: https://firefox-devtools-blocked-resources.glitch.me/

Mixed content and CORS work.

@David: so this is what I am seeing in the Console panel:

Request to access cookie or storage on “https://rules.quantcount.com/rules-p-JLXEY2nbGDmpc.js” was blocked because it came from a tracker and content blocking is enabled.

Is that what you have in mind?

Is this about blocking a request or blocking an access to cookie or storage?

Honza

Maybe this illustrates it. The storage errors have no relation to the blocked resources, but there are a few blocked resource errors without the right blocked state in the Network panel.

Seems like Necko can tell DevTools about blocked resources for CSP and mixed content. Are ETP and co working on a different level from Necko?

URL-Classifier cancels the nsIChannel for several reasons. Each one of them has its own error code.

1. Safe-Browsing errors: NS_ERROR_MALWARE_URI - NS_ERROR_PHISHING_URI - NS_ERROR_UNWANTED_URI - NS_ERROR_HARMFUL_URI
2. Tracking-protection error: NS_ERROR_TRACKING_URI
3. Fingerprinting-protection error: NS_ERROR_FINGERPRINTING_URI
4. Cryptomining-protection error: NS_ERROR_CRYPTOMINING_URI

The channel is canceled with one of these errors.
When this happen, we don't dispatch "http-on-failed-opening-request". Btw, this seems to be dispatched on by HttpChannelChild. What about non-e10s channels?

The documentation says:

• Called when asyncOpen synchronously failes e.g. because of any synchronously
• performed security checks. This only fires on the child process, but if
• needed can be implemented also on the parent process.
  https://searchfox.org/mozilla-central/rev/9eb2f739c165b4e294929f7b99fbb4d90f8a396b/netwerk/protocol/http/nsIHttpProtocolHandler.idl#94-99

URL-Classifier works asynchronously and it doesn't dispatch any notification. Instead, it cancels the channel and it informs the window about it in order to update the Content Blocking Log and the panel. We can introduce a new notification: "http-on-blocked-request".
Is this good enough for devtools network monitor?

:baku, that would be awesome! A single type which encompasses every blocked reason would be great!

(In reply to Andrea Marchesini [:baku] from comment #5)

URL-Classifier works asynchronously and it doesn't dispatch any notification. Instead, it cancels the channel and it informs the window about it in order to update the Content Blocking Log and the panel. We can introduce a new notification: "http-on-blocked-request".
Is this good enough for devtools network monitor?

Could we utilize API suggested in bug 1555057?

Specifically:

• nsIChannel.cancelWithReason(code, reason)
• http-on-cancel-request

Perhaps http-on-cancel-request is more generic and we could use it here too?

Honza

• http-on-cancel-request

I like this. Yes we can definitely use it. Valentin are you planning to work on this new notification?

In nsChannelClassifier.cpp I've added the reason why a channel's been blocked on its load info object. If nsHttpChannel on the parent is canceled with an error code (don't misplace this error code with the reason code, please) it will be visible if you intercept OnStopRequest call of the channel (which I believe devtools do on the parent, right?)

I think you already have everything you need. If something is broken, it would be good to rather find where the chain is unexpectedly broken, then to add new notification for something we already propagate a different way.

Note that if the set of reasons in the nsChannelClassifier.cpp - mozsearch was enhanced lately (like with the crypto-mining) a new reason to nsILoadInfo.idl - mozsearch should be added.

And note that I added the cancellation reason on load info because not always the code making blocking decisions has access to the channel (so it could not call any cancelWithReason apis, anyway)

(In reply to Andrea Marchesini [:baku] from comment #8)

• http-on-cancel-request
  I like this. Yes we can definitely use it. Valentin are you planning to work on this new notification?

I don't think I can get to this in the next few weeks. You can needinfo (:nhi) if you need someone on Necko to work on it.

:nhi, would you be available to help with this. Not showing blocked resources is a major gap for devs to understand potential breakage on their site.

:mconca, can this wait until 71 or later?

(In reply to Nhi Nguyen (:nhi) from comment #14)

:mconca, can this wait until 71 or later?

Secure Proxy and Fission take priority. If resources are not available for this work now, we should delay until 71.

Mike, could we Necko's help on the roadmap for Q4? Hiding blocked resources from devs makes debugging Tracking Protection and other interventions a lot harder.

(In reply to :Harald Kirschner :digitarald from comment #16)

Mike, could we Necko's help on the roadmap for Q4? Hiding blocked resources from devs makes debugging Tracking Protection and other interventions a lot harder.

This work is pending any additional work on Secure Proxy and DoH as those roll out to beta and then general audiences. Assuming smooth releases on those projects, there may be opportunities to pick this up in Q4.

(In reply to :Harald Kirschner :digitarald from comment #1)

Test site which blocks a set of resources based on CORS, CSP, Mixed content and url classification: https://firefox-devtools-blocked-resources.glitch.me/

Mixed content and CORS work.

Harald, do you have another test case?
This one doesn't seem to work anymore.

Honza

Tracking Protection: https://connect.facebook.net gets blocked (with Strict setting!). Gets a console warnings but not shown in Network panel.
CORS: https://bar.com/data.json gets blocked. Gets a CORS console warning, but is shown as successful 301 request in Network.

For uBlock use http://raymondhill.net/ublock/tiles1.html:
http://raymondhill.net/ublock/ad.html?something&ad_box_ gets blocked but is not shown in Network monitor at all.

(In reply to :Harald Kirschner :digitarald from comment #19)

Tracking Protection: https://connect.facebook.net gets blocked (with Strict setting!). Gets a console warnings but not shown in Network panel.
CORS: https://bar.com/data.json gets blocked. Gets a CORS console warning, but is shown as successful 301 request in Network.

I don't have a FB account. Can you please provide a log for this case? It should be visible if we do the necessary notification or not.

Please use MOZ_LOG=timestamp,nsHttp:5,ObserverService:5

Use command line args or env vars, I need child logs too.

Thanks.

I don't have a FB account. Can you please provide a log for this case? It should be visible if we do the necessary notification or not.

An FB account is not needed, the script is bring blocked by TP.

(In reply to :Harald Kirschner :digitarald from comment #21)

I don't have a FB account. Can you please provide a log for this case? It should be visible if we do the necessary notification or not.

An FB account is not needed, the script is bring blocked by TP.

OK, then I need a full, specific list of steps to reproduce. Thanks.

STR:

• Enable Strict mode for Tracking Protection
• Open Network panel on https://firefox-devtools-blocked-resources.glitch.me/
• Refresh

Resources from connect.facebook.net and bar.com are blocked (due to 1. TP and 2. CORS).

AR:
The blocked resources don't show as blocked in Network monitor
connect.facebook.net: Not shown at all.
bar.com: Shown, but not marked blocked.

Bug 1584183 moves the assignment of requestBlockingReason to a more common place and adds few new reasons for new classification codes + a MOZ_CRASH when a new classification code is added and is not remapped to a new blocking reason.

This fixes connect.facebook.net request not seen as blocked, STR from comment 23.

To make this fully work, the requestBlockingReason attribute must be read not only from http-on-failed-opening-request but also from OnStopRequest. This is up to the DevTools team, on Honza's request adding the note here.

For the bar.com > www.bar.com vetoed redirect case, bug 1584207 adds a missing forwarding of requestBlockingReason from the child process (where the vetoing happens) to the parent process. The reason is set on loadinfo of the old (source) redirect channel which is also the one being cancelled with NS_ERROR_DOM_BAD_URI in CORS listener proxy.

To expose the reason in the UI, the same applies here as for what has been said in comment 24 - read and update in onStopRequest, parent process

@mayhemer: Hi, any progress on this bug?
Anything I can help with?

Honza

talked on slack. bouncing the ball back to Honza O.

Honza, who is this work blocked on atm? Maybe related work happened in bug 1602090.

(In reply to :Harald Kirschner :digitarald from comment #23)

STR:

• Enable Strict mode for Tracking Protection
• Open Network panel on https://firefox-devtools-blocked-resources.glitch.me/
• Refresh

Resources from connect.facebook.net and bar.com are blocked (due to 1. TP and 2. CORS).

AR:
The blocked resources don't show as blocked in Network monitor
connect.facebook.net: Not shown at all.
bar.com: Shown, but not marked blocked.

This is now fixed for me by patch in bug 1555057
Closing as dup

Honza

A question here, can we display extension name instead of ID? Or should I open another ticket for this?

(In reply to lolipopplus from comment #32)

A question here, can we display extension name instead of ID? Or should I open another ticket for this?

The extension name is displayed in the Transferred column for me. See the attache screenshot.
Or do you have a test case where it isn't?
(in that case I'd file a follow up yes)

Honza

By extension name I mean the name displayed in about:addons or the name defined in manifest.json. So is there any misunderstanding here?

(In reply to lolipopplus from comment #34)

By extension name I mean the name displayed in about:addons or the name defined in manifest.json. So is there any misunderstanding here?

I filed bug 1638471 for it.