Bug 157198 – Web Inspector: Issues inspecting the inspector, pausing on breakpoints causes content to not load

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Joseph Pecoraro]

* SUMMARY
Mysterious issues inspecting the inspector, pausing on breakpoints causes content to not load.

* STEPS TO REPRODUCE
1. Inspect <http://bogojoker.com/shell/>
2. Set a breakpoint on formatted easySlider.min.js:56:21 ("if (autoplay)")
3. Select another resource in sidebar (facebox.js)
4. Reload
5. Inspect the inspector
6. inspector^2: Set breakpoint in TextEditor.prototype.revealPosition
7. inspector^1: Select breakpoint in sidebar to reveal its position
  => inspector^2 breakpoint triggers a few times, but ultimately continues
  => inspector^1 content never loads

* NOTES
Some logging and logging of protocol traffic is mysterious:

file:///Users/pecoraro/Build/Release/WebInspectorUI.framework/Resources/Models/SourceCode.js:113:20: CONSOLE LOG requestContent http://bogojoker.com/shell/js/easySlider.min.js
[native code]: CONSOLE LOG request: {"id":94,"method":"Network.getResponseBody","params":{"requestId":"0.73"}}
file:///Users/pecoraro/Build/Release/WebInspectorUI.framework/Resources/Models/SourceCode.js:113:20: CONSOLE LOG requestContent http://bogojoker.com/shell/js/easySlider.min.js
file:///Users/pecoraro/Build/Release/WebInspectorUI.framework/Resources/Views/TextEditor.js:441:20: CONSOLE LOG revealPosition - REVEAL
file:///Users/pecoraro/Build/Release/WebInspectorUI.framework/Resources/Views/TextEditor.js:433:24: CONSOLE LOG revealPosition - STASH
file:///Users/pecoraro/Build/Release/WebInspectorUI.framework/Resources/Views/TextEditor.js:441:20: CONSOLE LOG revealPosition - REVEAL
file:///Users/pecoraro/Build/Release/WebInspectorUI.framework/Resources/Models/GarbageCollection.js:32:23: CONSOLE ERROR

We never got a response for Network.getResponseBody. In fact, the promise is still pending within the Resource. How is this possible?

[Radar WebKit Bug Importer]

<rdar://problem/26011049>

[Joseph Pecoraro]

I think I found the issue.

When the Web Inspector itself is paused but the Inspected Page is not paused, then when the Web Inspector Process goes to dispatch a message (evaluating script in the page) we fail.

Here is the chain of events:

    InspectorProcess
      -> sendMessageToBackend( "Network.getResponseBody" )
        -> send Messages::WebInspector::SendMessageToBackend to WebContentProcess

    InspectorProcess
      -> PAUSE evaluating Web Inspector page JavaScript
        -> Run Nested Run Loop

    WebContentProcess
      - receive Messages::WebInspector::SendMessageToBackend message
        -> InspectorNetworkAgent::getResponseBody
          -> InspectorBackendDispatcher::sendMessageToFrontend
            -> WebInspector::sendMessageToFrontend (WebKit2 FrontendClient)
              -> send Messages::WebInspectorUI::SendMessageToFrontend to InspectorProcess

    InspectorProcess* (in nested runloop)
      - receive Messages::WebInspectorUI::SendMessageToFrontend
        -> WebInspectorUI::sendMessageToFrontend
          -> WebInspectorFrontendAPIDispatcher::dispatchMessageAsync
            -> ScriptController::executeScript
              -> Cannot execute script, we are paused, the message NEVER gets sent

So, in this scenario, WebInspectorFrontendAPIDispatcher can queue up messages while the inspector page is paused (something that we don't normally expect).

This also sheds light on another possible issue of APIs (JSContext / WKWebView) attempting to evaluating JavaScript on a paused page will just have their scripts dropped on the floor. However, that has always been the case, so I'm going to address that now.

[Joseph Pecoraro]

Created attachment 277765 [details]
[PATCH] Proposed Fix

Not going to commit-queue until I have tested a Debug build at least once. But this works.

I'm not sure it is perfect (pause/unpause happens while stepping, so in theory you could pause inside the new evaluation in between statements), however in practice InspectorFrontendAPIDispatcher is adding to a queue, so it actually isn't a problem. And again, this is only for inspecting the inspector right now.

[Blaze Burg]

View in context: https://bugs.webkit.org/attachment.cgi?id=277765&action=review

> Source/WebKit2/WebProcess/WebPage/WebInspectorFrontendAPIDispatcher.cpp:59
> +    ASSERT(m_queue.isEmpty());

This assertion seems wrong. What if evaluating a dequeued expression caused us to hit a breakpoint and suspend?

> Source/WebKit2/WebProcess/WebPage/WebInspectorFrontendAPIDispatcher.cpp:75
> +    evaluateOrQueueExpression(makeString("InspectorFrontendAPI.dispatch([\"", command, "\"])"));

Nit: evaluateOrEnqueueExpression

[Joseph Pecoraro]

(In reply to comment #4)
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=277765&action=review
> 
> > Source/WebKit2/WebProcess/WebPage/WebInspectorFrontendAPIDispatcher.cpp:59
> > +    ASSERT(m_queue.isEmpty());
> 
> This assertion seems wrong. What if evaluating a dequeued expression caused
> us to hit a breakpoint and suspend?

We don't appear to allow pausing when running when already nested. Or at least I was unable to (console.log worked, but hitting a breakpoint did not).

[WebKit Commit Bot]

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

Clearing flags on attachment: 277765

Committed r200276: <http://trac.webkit.org/changeset/200276>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.