Closed Bug 906239 Opened 11 years ago Closed 8 years ago

Ajax requests should have a stack trace so you can figure out what caused a request to be sent


(DevTools :: Netmonitor, defect, P1)



(Not tracked)



(Reporter: fitzgen, Assigned: tromey)


(Blocks 1 open bug)


(Whiteboard: [polish-backlog][devtools-platform])


(2 files)

Chrome devtools has this and it seems super handy. Just found out via reddit[0].

Blocks: async-stacks
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 )
Priority: -- → P1
Whiteboard: [devedition-40]
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.
Depends on: 1148593
Whiteboard: [devedition-40] → [polish-backlog]
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.
Whiteboard: [polish-backlog] → [polish-backlog][devtools-platform]
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.
Assignee: nobody → ttromey
The front end bits here will be simpler & better once bug 1211525 is done, so marking
this as a dependent.
Depends on: 1211525
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 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.
Closed: 8 years ago
Resolution: --- → DUPLICATE
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.