[Webkit-unassigned] [Bug 33096] [Qt] DRT: Support evaluateInWebInspector(), setTimerProfilingEnabled() and display().

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33096





--- Comment #38 from Robert Hogan <robert at roberthogan.net>  2010-01-25 11:26:31 PST ---
(In reply to comment #37)
> From my understanding, calling m_frontend.set(0) should have no effect on the
> life of InspectorClientQt::m_inspectorView (and QWebInspector's frontend).
> InspectorController::m_frontend is a proxy object to call javascript functions
> and forward data in the inspector web page.
> 
> Were you able to make it crash without this line just by running the tests?

Yes, exactly. The DRT closes the webinspector directly using
inspectorController()->close() - which is what the other DRTs do too. The same
QWebPage persists between tests so that's all that's required, it also means
that the DRT doesn't have to worry about displaying the webinspector.

You're right that my comment is incorrect - m_frontend is a red herring.

The correct explanation is:

Because Qt keeps a copy of the inspectorView value in QWebInspector::frontend,
it means that when you call inspectorController()->close() inspectorView is
going to get deleted by:

    if (m_page) {
        if (!m_page->mainFrame() || !m_page->mainFrame()->loader() ||
!m_page->mainFrame()->loader()->isLoading()) {
            m_page->setParentInspectorController(0);
            m_page = 0;
        }
    }

leaving the reference stored in QWebInspectorPrivate::frontend dangling. This
comes back to bite when the InspectorController goes to create the inspector
page for the next test in the DRT run when we call InspectorController::show():
a new m_page gets created(m_page = m_client->createPage();) and when
setFrontEnd() gets called there it hits:

if (frontend)
        frontend->setParent(0);

and since 'frontend' (i.e. m_page) was actually deleted by the
InspectorController it crashes when attempting to setParent.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.