Chrome devtools has this and it seems super handy. Just found out via reddit[0]. [0] http://www.reddit.com/r/javascript/comments/1khgqo/how_do_you_diagnose_what_javascript_is_making_an/

related: bug 821610 and bug 832983.

Marking this with devedition-40, probably wishful thinking. It is *extremely* useful to have a source path / lineno related to an XHR request ( but more generally, just wherever the resource being loaded originated form in the user's code )

It wasn't totally clear to me if this is a dup of bug 1145900, or if this bug includes displaying the stack trace in the net monitor. So, leaving it open and marking the dependency.

See also bug 1206403. One thing to note here is that bug 1154900 added async stacks to the XHR callback objects -- but not to the XHR object itself; the main difference being that there's also no really good way to get at these saved stacks unless an error occurs in the course of executing one of the callbacks.

I dug into this a bit. I can make it work with just one (1) egregious hack. So yay! I have to reinstate one event eliminated by bug 806753 to make this work with e10s. Even with this change I am still not sure that my approach to correlating http events between the content and parent processes makes sense. To be clear what I have will associate the stack trace at the time of the XHR "send" request with a given entry in the network panel. I'm not sure if this is what is wanted. It might be nice to also know the location of the "new XMLHttpRequest" -- but this is harder to get at. It's possible, even easy, to add a stack trace to the XMLHttpRequest object. However, this object isn't exposed to the network observers. They get an nsIChannel instead, with no link back. Maybe this could be added if it is really desirable.

The front end bits here will be simpler & better once bug 1211525 is done, so marking this as a dependent.

WIP patch to notify http-on-opening-request observers even in the content process. This is needed to capture an XHR stack trace at the appropriate place when e10s is in use.

WIP patch to collect XHR stack traces and send them to the front end.

As the submitter of duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=1249583 I wonder what's the status here. There is a patch by @tromney, but there is no review and also not marked (tagged) for review wanted?

The attached patch only handles the back end -- it collects the stack trace. However, it doesn't display the stack trace to the user. For that I thought it would be simpler to wait for the refactorings in bug 1211525 to land.