Should be exposed in cause column, similar to lazy-loaded requests.

Why is this in Core:Net?

Harald to provide the cause mappings that we want to expose from internalContentPolicyType.

Let's stick to exposing preload for now for the various causes that list it.

Honza, do we already have access to the internal policy type in the actor?

Yes, it's nicely accessible, see the following patch:

--- a/devtools/server/actors/network-monitor/network-observer.js
+++ b/devtools/server/actors/network-monitor/network-observer.js
@@ -674,16 +674,18 @@ NetworkObserver.prototype = {
       ? referrerInfo.getReferrerPolicyString()
       : "";
     httpActivity.fromServiceWorker = fromServiceWorker;

     if (extraStringData) {
       event.headersSize = extraStringData.length;
     }

+    console.log("_createNetworkEvent " + channel.URI.spec + ", " + channel.loadInfo.internalContentPolicyType);
+
     // Determine the cause and if this is an XHR request.
     let causeType = Ci.nsIContentPolicy.TYPE_OTHER;
     let causeUri = null;
     let stacktrace;

     if (channel.loadInfo) {
       causeType = channel.loadInfo.externalContentPolicyType;
       const { loadingPrincipal } = channel.loadInfo;

I can see various type for random page, for example:

• TYPE_INTERNAL_SCRIPT_PRELOAD
• TYPE_INTERNAL_IMAGE_FAVICON
• TYPE_INTERNAL_IMAGE
• TYPE_INTERNAL_STYLESHEET_PRELOAD

All the possible types are available here:
https://searchfox.org/mozilla-central/rev/97cb0a90bd053de87cd1ab7646d5565809166bb1/dom/base/nsIContentPolicy.idl#27

There are the following preload cases:

• TYPE_INTERNAL_SCRIPT_PRELOAD
• TYPE_INTERNAL_IMAGE_PRELOAD
• TYPE_INTERNAL_STYLESHEET_PRELOAD
• TYPE_INTERNAL_MODULE_PRELOAD

Btw. you can also see (in the patch above) that we have access to channel.loadInfo.externalContentPolicyType. This field is explained here
https://searchfox.org/mozilla-central/rev/97cb0a90bd053de87cd1ab7646d5565809166bb1/netwerk/base/nsILoadInfo.idl#586

Honza

OK, the proposal from comment 4 won't work. The wording is quite confising here - PRELOAD in the CSP internal types actually means "speculative loads". A regular consuming tag (e.g. <script>) hit during the HTML5 parser prescan phase will start a channel with such an internal CSP type (e.g. TYPE_INTERNAL_SCRIPT_PRELOAD). If there is <link rel=preload as=script> for that resource found before the regular tag, it will start a load behaving exactly the same (a speculative load with TYPE_INTERNAL_SCRIPT_PRELOAD).

Hence, the content policy type (internal) doesn't hold the right information you want here.

I noticed there was the initiatorType property, which should be changed to carry that information independently on this particular bug (already sketched here, I will file a bug to expose it on other resource types as well). That than just opens the question if for the information you want to display for this bug that property would be the right source. Honza, what do you think?

:mayhemer, would it be correct to rename the current "preload" label (that is deferred from TYPE_INTERNAL_SCRIPT_PRELOAD) to "speculative"; so devs understand why a request happened?

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

:mayhemer, would it be correct to rename the current "preload" label (that is deferred from TYPE_INTERNAL_SCRIPT_PRELOAD) to "speculative"; so devs understand why a request happened?

If you tell me more about that tag (where it's set and where it's shown in the UI and what are other possible values) then I can decide.

(In reply to Honza Bambas (:mayhemer) from comment #7)

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

:mayhemer, would it be correct to rename the current "preload" label (that is deferred from TYPE_INTERNAL_SCRIPT_PRELOAD) to "speculative"; so devs understand why a request happened?

If you tell me more about that tag (where it's set and where it's shown in the UI and what are other possible values) then I can decide.

Question: you want to show the information that the request has been initiated by <link preload> somewhere else, or using this label (column?)

It would be shown in the initiator column, "speculative script" in the case of a speculatively loaded script tag, similar to "lazy" in bug 1615305. Tooltip on the label and a note in the request details can link to MDN for further docs.

Got it, thanks.

So few examples how it should look like (according how I understand it now):

Yes, that sums it up perfectly of what we are aiming for!

OK, thanks.

I can do the "preload ${resource-type}" option for <link preload> tags initiated channels as part of bug 1639901. I'll leave the distinction of "speculative" (99.9% of them) and regular (for dynamically added tags or some corner case situations) for followup bugs and let it be done by respective module peers. I'm not sure we need that much to provide the "speculative" and "regular" distinction.

Please disregard previous comment. I wanted to reuse the "initiator" column and though it's fed solely from the PerformanceResourceTiming.initiatorType information on the channel. It's not and values for that attribute are actually quite limited.

Hence, we need to discuss how this should be exposed on the channel. I see following options:

• as we are monitoring only HTTP requests (while preload can be made for any schema!) add a bool property on nsIHttpChannel
• add a property on nsILoadInfo; but loadinfo should only contain stuff related to security, which this is not
• have a new interface nsIPreloadingChannel with the bool property and let channels we want to carry this information implement it
• add new CSP internal types for actual link rel=preload requests (for each supported type) and get also the naming right: what is now PRELOAD but actually is a speculative load, should be renamed to SPECULATIVE and use PRELOAD for <link preload> channels

The simplest is the first option (nsIHttpChannel) and I think sufficient even mid- or long-term. The most correct, but with some work, is the last option (new CSP types).

Baku, Harald, what do you think about comment 13?

Forwarding to Honza for the technical questions in comment 13

:mayhemer, could you or somebody from your team help with the platform work outlined in comment 13?

I think fixing the CSP internal types is the best way. We then don't need new exposed properties on channels and reuse what we already have. But it's a bit more work and needs to be carefully reviewed.

I can file new bugs and ask Nhi to find assignees. I can eventually work on that too.