Bug 66223 – [Qt] inspector/debugger/open-close-open.html fails on Qt port

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Qt

[Zoltan Herczeg]

Not sure this is platform specific, but it surely fails on Qt.

InspectorTest.evaluateInPage = function(code, callback)
{
    callback = InspectorTest.safeWrap(callback);

    function mycallback(error, result, wasThrown)
    {
        if (!error)
            callback(WebInspector.RemoteObject.fromPayload(result), wasThrown);
    }
    RuntimeAgent.evaluate(code, "console", false, mycallback);
}

RuntimeAgent.evaluate does not do anything when it runs the second time (at least mycallback is not called). Could someone tell me which function runs for RuntimeAgent.evaluate? Something is bound to this property by utilities.js, but I don't know where it came from.

[Pavel Feldman]

(In reply to comment #0)
How is this related to zero-path-square-cap-rendering2.svg?

RuntimeAgent issues a command to the inspected page via InspectorFrontendHost.sendMessageToBackend where InspectorFrontendHost is a native bound object injected into the front-end context.

[Zoltan Herczeg]

Ooops, sorry for the wrong name. That is a different bug.

inspector/debugger/open-close-open.html is the reight one.

[Zoltan Herczeg]

WebCore::InspectorController::show
Source/WebCore/inspector/InspectorController.cpp:326

Runs earlier than

WebCore::InspectorFrontendHost::disconnectFromBackend
Source/WebCore/inspector/InspectorFrontendHost.cpp:175

Thus, it destroys the window, and cause this test to fail.

Both are called from WebCore/page/DOMTimer.cpp thus, there is a usual async problem here.

[Zoltan Herczeg]

Created attachment 104474 [details]
fix

[Pavel Feldman]

Comment on attachment 104474 [details]
fix

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

> LayoutTests/http/tests/inspector/inspector-test.js:376
> +        setTimeout(function() { callback(); }, 0);

layoutTestController.closeWebInspector -> InspectorController::close -> InspectorFrontend::disconnectFromBackend -> setTimeout(WebInspector.disconnectFromBackend) -> InspectorFrontendHost.disconnectFromBackend -> closing the inspector.

This does prove that callback is called before inspector is closed, but this is somehow not critical for the rest of the ports sharing the logic. What is the failure symptoms? Could it be difference in the DRT implementation? (DRT should be closing inspector after each test synchronously).

[Zoltan Herczeg]

> layoutTestController.closeWebInspector -> InspectorController::close -> InspectorFrontend::disconnectFromBackend -> setTimeout(WebInspector.disconnectFromBackend) -> InspectorFrontendHost.disconnectFromBackend -> closing the inspector.
> 
> This does prove that callback is called before inspector is closed, but this is somehow not critical for the rest of the ports sharing the logic. What is the failure symptoms? Could it be difference in the DRT implementation? (DRT should be closing inspector after each test synchronously).

Probably there is a difference. Actually inspector is an entity resource in Qt, only one is allowed to be exists. The opening is synchronous, normally based on the path:

if (isWebInspectorTest(url))
     layoutTestController()->showWebInspector();

Symptoms: it opens a new inspector, and close it right after the next timer event is called. Since there is only one exists at a time there is no inspector after the closing.

Besides, the closing is normally done just before the end of the test by:

function closeInspectorAndNotifyDone()
{
    if (window._watchDogTimer)
        clearTimeout(window._watchDogTimer);

    layoutTestController.closeWebInspector();
    setTimeout(function() {
        layoutTestController.notifyDone();
    }, 0);
}

And that is an asynchronous operation.

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.