1608599 - Flag speculative status for requests in the Network panel

Status: RESOLVED FIXED

(Core :: Networking, enhancement, P3)

Description

[:Harald Kirschner :digitarald]

Off the cuff, the cause column would probably be a good target that could combine type+preload (similar to (raced)), but let's discuss further to scope out a solution.

Stretch goal: Stack trace points to the HTML location that defines the preload entry.

Comment 1

[:Harald Kirschner :digitarald]

preloaded scripts already seems to be an internal content policy type: https://searchfox.org/mozilla-central/source/dom/base/nsContentUtils.h#3372

Honza, could we get access to them to have more fine-grained causes?

Comment 2

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

Dragana, could we get access to nsIContentPolicy for a request? Perhaps through channel.loadInfo?

Honza

Comment 3

[Dragana Damjanovic [:dragana]]

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #2)

Dragana, could we get access to nsIContentPolicy for a request? Perhaps through channel.loadInfo?

Honza

the attribute is in loadInfo but it is not accessible from scripts:
https://searchfox.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl#556
You probably need it from a js.

Comment 4

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

(In reply to Dragana Damjanovic [:dragana] from comment #3)

the attribute is in loadInfo but it is not accessible from scripts:
https://searchfox.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl#556
You probably need it from a js.

Correct, DevTools are entirely written in JS and so, we are consuming all platform APIs from JS.

Is it possible to expose the nsContentPolicyType internalContentPolicyType(); to scripts?

DevTools would benefit from having access to the attribute.
The Network panel could provide more detailed info so, the user can understand how preload logic works and impacts the page load.

Thanks!
Honza

Comment 5

[Dragana Damjanovic [:dragana]]

We can expose internalContentPolicyType to js.
rel=preload is not ready yet. I will put this bug as a part of the rel=preload project as it should be fix as a part of that project.

Do you need it earlier?

Comment 6

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

(In reply to Dragana Damjanovic [:dragana] from comment #5)

We can expose internalContentPolicyType to js.
rel=preload is not ready yet. I will put this bug as a part of the rel=preload project as it should be fix as a part of that project.

Do you need it earlier?

If fixing this bug is relatively small change (e.g. changing idl definition etc.) it would be great to have it earlier (also AFAIK there is no forecast for rel=preload so, it might take a while). GSoC application phase (edit) will start March 16 and there are students that could help us testing this new API in DevTools and build innovative features.

Honza

Comment 7

[Dragana Damjanovic [:dragana]]

Nhi, can you prioritize this?

Comment 8

[Nhi Nguyen (:nhi)]

I think this should be done as part of the rel=preload project, which is in our roadmap. Leaving this as P3.

Comment 9

[Sonakshi Saxena]

Hi @honza(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #6)

(In reply to Dragana Damjanovic [:dragana] from comment #5)

We can expose internalContentPolicyType to js.
rel=preload is not ready yet. I will put this bug as a part of the rel=preload project as it should be fix as a part of that project.

Do you need it earlier?

If fixing this bug is relatively small change (e.g. changing idl definition etc.) it would be great to have it earlier (also AFAIK there is no forecast for rel=preload so, it might take a while). GSoC application phase (edit) will start March 16 and there are students that could help us testing this new API in DevTools and build innovative features.

Honza

Hey! I am an Outreachy applicant, and I was hoping if you could give me some direction in solving this bug.

Thanks!
Sonakshi

Comment 10

[Dragana Damjanovic [:dragana]]

(In reply to Sonakshi Saxena from comment #9)

Hi @honza(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #6)

(In reply to Dragana Damjanovic [:dragana] from comment #5)

We can expose internalContentPolicyType to js.
rel=preload is not ready yet. I will put this bug as a part of the rel=preload project as it should be fix as a part of that project.

Do you need it earlier?

If fixing this bug is relatively small change (e.g. changing idl definition etc.) it would be great to have it earlier (also AFAIK there is no forecast for rel=preload so, it might take a while). GSoC application phase (edit) will start March 16 and there are students that could help us testing this new API in DevTools and build innovative features.

Honza

Hey! I am an Outreachy applicant, and I was hoping if you could give me some direction in solving this bug.

Thanks!
Sonakshi

You need to remove noscript and notxpcom from
https://searchfox.org/mozilla-central/rev/c888ecff616737e27286d99167edafb6805e8494/netwerk/base/nsILoadInfo.idl#560
you need to remove that line. I think that is all that is needed.

Comment 11

[Sonakshi Saxena]

Okay, sure. Thanks! Will put a patch for this :)

Comment 12

[Sonakshi Saxena]

Attachment: Bug 1608599 - Add preloaded status for requests in the Network panel

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0cdc6c8cee2d
Add preloaded status for requests in the Network panel r=valentin

Comment 14

[Valentin Gosu [:valentin] (he/him)]

I assume we'll use bug 1624368 for the netmonitor work?

Comment 15

[:Harald Kirschner :digitarald]

I assume we'll use bug 1624368 for the netmonitor work?

Just talking to Honza about this. That is correct.

Comment 16

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/0cdc6c8cee2d

Comment 17

[Honza Bambas (:mayhemer)]

Sorry to chime in so late, but what do you expect from this attribute? The content policy type doesn't say ANYTHING about <link preload> invocation of the request, not at all. The new preload code at the moment doesn't exist, so there is nothing to produce the information a request is a rel=preload. You apparently misplaced "speculative load" with "rel=preload". Those are two different things. Only fact is that rel=preload started loads will be nothing more than speculative loads with some additional properties (and those properties are what you are looking for!) There are speculative loads, right now, for regular tags as well, and actually all (or at least most) markup invoked loads are speculative. Will this patch just tell devtools that all our such loads are rel=preloads? That would really be wrong. This bug is definitely not FIXED.

Comment 18

[:Harald Kirschner :digitarald]

So what did this bug land then? Sounds like we should file a follow up bug to rename the preload label added to speculative?

Comment 19

[Honza Bambas (:mayhemer)]

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

So what did this bug land then?

Nothing at all related to preload.

Sounds like we should file a follow up bug to rename the preload label added to speculative?

Yes, because right now it's pretty confusing if we want to add "preload" info there as well.