This allows the client code to handle fewer replay state cases because the replay manager can asynchronously "make it so". It also makes capture/replay more robust, because the manager can asynchronously disable breakpoints, continue the debugger, etc. before carrying out commands. For example, if a startCapturing() command is issued during replay, the manager can construct a promise chain to stop replaying, unload the current segment, and start capturing. Without an async promise API, each client would have to manually get the replay engine to an acceptable state.
<rdar://problem/17798570>
Created attachment 235448 [details] Patch
Comment on attachment 235448 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=235448&action=review > Source/WebInspectorUI/UserInterface/Controllers/ReplayManager.js:231 > + switchSession: function(sessionId) { // --> () What is the "// --> ()" for? > Source/WebInspectorUI/UserInterface/Controllers/ReplayManager.js:253 > + }) > + .then(function ensureSessionDataIsLoaded(session) { I like these on the same line. > Source/WebInspectorUI/UserInterface/Views/ReplayDashboardView.js:124 > + }).then(function() { Yay! Same line.
Comment on attachment 235448 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=235448&action=review >> Source/WebInspectorUI/UserInterface/Controllers/ReplayManager.js:231 >> + switchSession: function(sessionId) { // --> () > > What is the "// --> ()" for? This is my (crappy) syntax for documenting which functions return a promise, and what the fulfilled promise value is (if any). Contrast to the getSegment() function. >> Source/WebInspectorUI/UserInterface/Controllers/ReplayManager.js:253 >> + .then(function ensureSessionDataIsLoaded(session) { > > I like these on the same line. OK
If it's okay with you, I'm going to land this without the UI changes, since those aren't reviewed yet.
Committed r172161: <http://trac.webkit.org/changeset/172161>