Bug 20309 - Web Inspector: link async responses back to async requests with stack traces
Summary: Web Inspector: link async responses back to async requests with stack traces
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2008-08-06 15:19 PDT by Andy Clark
Modified: 2017-04-11 22:53 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Clark 2008-08-06 15:19:10 PDT
In AJAX programming, most interaction with the server occurs asynchronously: the app sets a callback function (onreadystatechange) on the XMLHttpRequest object which gets called when the request state changes. If an error occurs (or the debugger stops at a set breakpoint) during the callback, only the stack starting from onreadystatechange is visible to the user. And with multiple requests happening at the same time, it is difficult for the developer to associate the code path that issued the request to the code path of the response.

The request for enhancement is for the debugger to take a snapshot of the stack whenever an asynchronous request is made. Then, when the response is handled, a unified stack is shown to the user, including the full stack prior to the request. This should also work for chained async requests. For example, if the response for the async request FOO issues an async request BAR, then the response for BAR should show the the stack prior to the FOO request combined with the stack in the FOO response up to before the BAR request *and* the stack of the BAR response.

Once support is added to snapshot stacks and then display them unified as a single stack in the debugger, this feature can be applied to all asynchronous (or disconnected) code flows. This is primarily useful for asynchronous XML HTTP requests but also for setTimeout and setInterval. A separate setting for setInterval would probably be a good idea since it could continue forever whereas async requests and setTimeout are limited to the (usually short) chain of requests.
Comment 1 Mark Rowe (bdash) 2008-08-06 15:40:37 PDT
<rdar://problem/6130993>
Comment 2 Matt Baker 2017-04-11 22:49:55 PDT
Basic support for asynchronous call stacks was added in r209062, and includes support for timers and animation frames:

Web Inspector: Debugger should have an option for showing asynchronous call stacks
https://webkit.org/b/163230

Web Inspector: Debugger support for chained async call stacks
https://webkit.org/b/164556

Web Inspector: Show async stack traces for workers
https://webkit.org/b/165235

Web Inspector: Need some limit on Async Call Stacks for async loops (rAF loops)
https://webkit.org/b/165633
Comment 3 Matt Baker 2017-04-11 22:53:53 PDT
Additional async scenarios needing coverage:

Web Inspector: capture async stack trace when web content calls addEventListener, window.postMessage, fetch, XHR.send
https://webkit.org/b/167083

Web Inspector: capture async stack trace when workers/main context posts a message
https://webkit.org/b/167084

Web Inspector: capture async stack trace when a Promise is created, resolved, rejected, or chained
https://webkit.org/b/167085

Web Inspector: capture an async stack trace for async/await functions
https://webkit.org/b/167086