898614 - Add ability to trace a resource loaded back to the code where it was loaded from

Status: RESOLVED DUPLICATE of bug 1230922

(DevTools :: Netmonitor, defect, P1)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

# Waterfall info on dependance of resources So far, we don't even have a
# waterfall of resource loading. But when we get one, here is a feature request.
# Description of the use-case: I'm debugging a page with many third-party
# scripts. I want to know who is including this heavy image. So I should see
# some relations between resources.

etherpad: https://etherpad.mozilla.org/sudweb-devtools-progress
original email: http://markmail.org/thread/qfwfxryspiwzfad3#query:+page:1+mid:qfwfxryspiwzfad3+state:results

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Jordan: can you add and estimate of difficulty= in the whiteboard for this bug?

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

I'm not sure if we have that info, and if we don't, how we'd get it -- I'm only familiar with the client; pinging Honza

Comment 3

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

(In reply to Jordan Santell [:jsantell] [@jsantell] (Please needinfo) from comment #2)
> I'm not sure if we have that info, and if we don't, how we'd get it -- I'm
> only familiar with the client; pinging Honza
I am not aware of any APIs that would give us the originator of a request.

Andrea, do we have Necko API somewhere around nsIHttpRequest that would give us (devtools) info about what triggered an HTTP request? Like: foo.com/ad.jpg <- bar.net/style.css <- adcompany.com/script.js 

Honza

Comment 4

[Andrea Marchesini [:baku]]

> Andrea, do we have Necko API somewhere around nsIHttpRequest that would give
> us (devtools) info about what triggered an HTTP request? Like:
> foo.com/ad.jpg <- bar.net/style.css <- adcompany.com/script.js 

No. We don't have nothing like this. The only thing we have is the loadGroup that tells you the top-level request, but I guess you already have that.

Comment 5

[Sebastian Zartner [:sebo]]

If its too difficult to save the whole stack of requests, I guess it would already be enough to have the information about the direct initiator of a request. The original initiator can be traced back by looking at each request.

Sebastian

Comment 6

[Sebastian Zartner [:sebo]]

J. Ryan proposed in bug 1230922 that this bug may just add the platform API and bug 1230922 may be used to implement the UI.
I think that's a good idea.

Sebastian

Comment 7

[Sebastian Zartner [:sebo]]

Actually, I wonder whether we should mark this bug as a duplicate of bug 563623 (which is already split up into smaller tasks).

Sebastian

Comment 8

[Sebastian Zartner [:sebo]]

ni'ing Jeff regarding comment 7.

Sebastian

Comment 9

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Sebastian Zartner [:sebo] from comment #8)
> ni'ing Jeff regarding comment 7.
> 
> Sebastian

It *seems* like this bug should depend on that one - it is in Core and this is a Netmonitor bug.

Comment 10

[Sebastian Zartner [:sebo]]

Sorry to ni you again, but it's still a bit unclear for me what this bug is about, then. Is it about creating the UI for the origin information within the network panel? If so, I'd say it's a duplicate of bug 1230922 (which has more detailed info), right?

Sebastian

Comment 11

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Sebastian Zartner [:sebo] from comment #10)
> Sorry to ni you again, but it's still a bit unclear for me what this bug is
> about, then. Is it about creating the UI for the origin information within
> the network panel? If so, I'd say it's a duplicate of bug 1230922 (which has
> more detailed info), right?
> 
> Sebastian

That sounds reasonable - and please just go ahead and make changes.