Sebastian Zartner [:sebo] Reporter
	Description • 9 years ago

The Network panel should provide information about the initiator of each network request.

This information differs between the different origins of the requests:

1. When parsing HTML, SVG, etc.
For requests caused by parsing HTML (e.g. <script> or <img> tags) the related HTML file (and maybe line and column numbers) and/or HTML node may be displayed.
Clicking it would switch to the Inspector panel and select the element there.

2. When parsing CSS
For requests caused by parsing CSS (e.g. url() or image() notations) the related CSS file (and maybe line and column numbers) and/or CSS rule may be displayed.
Clicking it would switch to the Style Editor panel and highlight the related property (or even the related value) there.
Hovering it could display the related CSS rule within a tooltip.

3. When executing JavaScript
For requests caused by JavaScript functions (e.g. XMLHttpRequest.send() or appending a <script> element to the DOM structure) the related script URL (and maybe line and column numbers) and/or function name may be displayed.
Clicking it would switch to the Debugger panel and highlight the related function there.
Hovering it could display the stack trace for the function call within a tooltip.

4. When page is called
For requests caused by the user there would be a note displayed that the request was initiated by him/her (i.e. by entering a URL into the awesome bar).

5. Unknown origin
For requests that are caused by something that is not handled explicitly a note is displayed telling so.

This bug requires bug 563623 to be implemented.
Note that this feature is already available in Chrome via the 'Initiator' column in its Network panel.

Sebastian

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 1 • 9 years ago

This is very similar to bug 898614.  Perhaps bug 898614 would just add the platform API, and this could be used to integrate into the tools.

	Sebastian Zartner [:sebo] Reporter
	Comment 2 • 9 years ago

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #1)
> This is very similar to bug 898614.  Perhaps bug 898614 would just add the
> platform API, and this could be used to integrate into the tools.

Sounds good to me.

Sebastian

	Sebastian Zartner [:sebo] Reporter
	Comment 4 • 8 years ago

Brian, I just saw that the main part of this got implemented in bug 1134073.
My description of this bug includes more features than the other one. So, should this be handled as an improvement to the feature?

Sebastian

	Jarda Snajdr [:jsnajdr]
	Comment 5 • 8 years ago

1 and 2 - links that are directly in HTML/SVG/CSS: currently, the top-level document URL is displayed in the "Cause" tooltip, even when the request is initiated by a stylesheet. This can be easily improved by displaying the request's triggeringPrincipal (which is the CSS URL) instead of the loadingPrincipal (which is the top-level document). If we also wanted to display line and column numbers, that would require adding a platform API (adding context to requests, as described by bz in bug 563623).

3 - JS stacks: already done in bug 1134073.

4 - user actions, i.e. when document is loaded or reloaded: currently, we are showing a JS stack trace from the browser chrome, which can be rather confusing for the user. I'd like to improve this in bug 1280266. Also, we can take advantage of the nsIDOMWindowUtils::isHandlingUserInput attribute, and display its value in some useful way.

So, I think that further progress will be incremental improvements and follow-ups to what's been already done in bug 1134073.

	Sebastian Zartner [:sebo] Reporter
	Comment 6 • 8 years ago

Thank you for the response, Jarda! So I turn this bug into a meta bug and file bugs for the different improvements.

Sebastian

	Jonathan Watt [:jwatt]
	Comment 7 • 6 years ago

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)