Steps: 1) Enable break on All Exceptions 2) Run this code in the console from bug 156114: crypto.webkitSubtle.generateKey({ name: "RSA-OAEP", modulusLength: 2048, publicExponent: new Uint8Array([0x01, 0x00, 0x01]), hash: {name: "SHA-256"} }, true, ["encrypt", "decrypt" ]).then((keypair) => { console.log("Generated Key Pair:", keypair); return crypto.webkitSubtle.exportKey("jwk", keypair.publicKey); }).then((keydata) => { console.log("Key Data:", keydata); }).catch((error) => { console.log("Error: ", error); }); 3) It should stop on the return line with an exception 4) Try to continue 5) console.log should be logged with the error from the Promise catch 6) Still appear paused, try to continue Results: Appears to stay paused, but it does resume. Error is logged when inspecting Inspector: [Error] DebuggerManager.resume failed: – Error: Can only perform operation while paused. Error: Can only perform operation while paused. _dispatchResponseToPromise — InspectorBackend.js:307 _dispatchResponse — InspectorBackend.js:272 dispatch — InspectorBackend.js:149 dispatchNextQueuedMessageFromBackend — MessageDispatcher.js:42 (anonymous function) (DebuggerManager.js:194) promiseReactionJob
<rdar://problem/26030890>
You might also need to click continue a couple times to get the console.log to appear. Then further continues will log the error in the Inspector. We need to make sure the debugger UI never gets out of sync with the backend, which is what appears to be happening here. You can use the Inspector when it is in this state, but a developer will think the page is still pauses and will be confused.
The issue is due to the DebuggerManager not resuming the backend when it resumed the front end: In the test case, a Promise throws an exception on rejection. Since this is in builtin code, the DebuggerManager detects that there are no active frames on the stack, and chooses to resume the front-end. Unfortunately, it did not resume the back end as well. As a result, the backend sits in its event loop perpetually. A patch with the fix is coming shortly.
(In reply to comment #3) > The issue is due to the DebuggerManager not resuming the backend when it > resumed the front end: > > In the test case, a Promise throws an exception on rejection. Since this is > in builtin code, the DebuggerManager detects that there are no active frames > on the stack, and chooses to resume the front-end. Unfortunately, it did > not resume the back end as well. As a result, the backend sits in its event > loop perpetually. > > A patch with the fix is coming shortly. Correction: there's more to this than what we thought above. With the explicit call to the resume the backend, the backend does get resumed. However, the front end still looks like it is stopped on a breakpoint.
Joe suggested, for a test, that I change the bail check at the top of DebuggerManager's _didResumeInternal() to "if (!this._paused) return". With that plus the explicit call to DebuggerAgent.resume() added to debuggerDidPause(), the issue appears to be resolved. That said, I'm not sure that this is the proper fix though. Sending this bug over to Joe since the bug appears to be at the Inspector level.
Created attachment 279467 [details] [PATCH] Proposed Fix
Comment on attachment 279467 [details] [PATCH] Proposed Fix Clearing flags on attachment: 279467 Committed r201211: <http://trac.webkit.org/changeset/201211>
All reviewed patches have been landed. Closing bug.