Web Inspector: Can't resume Debugger after breaking on exception in Promise

• Component: Web Inspector
• Status: RESOLVED FIXED

[Timothy Hatcher]

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

[Radar WebKit Bug Importer]

<rdar://problem/26030890>

[Timothy Hatcher]

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.

[Mark Lam]

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.

[Mark Lam]

(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.

[Mark Lam]

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.

[Joseph Pecoraro]

Created attachment 279467 [details]
[PATCH] Proposed Fix

[WebKit Commit Bot]

Comment on attachment 279467 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 279467

Committed r201211: <http://trac.webkit.org/changeset/201211>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.