[Webkit-unassigned] [Bug 109216] New: [Qt][WK2] Crash on window resize if WebProcess is closed/crashed

[bugzilla-daemon at webkit.org]

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

           Summary: [Qt][WK2] Crash on window resize if WebProcess is
                    closed/crashed
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Major
          Priority: P1
         Component: WebKit Qt
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: savagobr at yahoo.com


Steps to reproduce:
a) Start snowshoe
b) Kill QtWebProcess
c) Window resize

Cause of crash: calls to WebKit::DrawingAreaProxy without testing for pointer validity.

When the WebProcess was closed (or crashed), WebKit::WebPageProxy will set its DrawingAreaProxy data member pointer to null. At a resize event, QQuickWebView will simply call into its pimple updateViewportSize() which access the pointer to the WebPageProxy that is now set to null.

Some ports (e.g. EFL), will load an error page at WebProcess crash with the side effect forcing its re-spawn, which is not the case of Qt. Makes me wonder if we should have similar behavior?

This patch adds a test for the validity of WebPageProxy pointer which fixes the crash.

I considered the idea of creating a test for it, but it would either result in:
a) Having a test using a native API (e.g. POSIX) to inspect for QtWebProcess (i.e. inspecting /proc in linux) and kill it, followed by resizing a QQuickWebView client (QML WebView). This is not ideal since it would result in a test that only runs in a specific environment while Qt runs everywhere(Tm)!

b) Force QQuickWebView (or friends) to somehow export the process ID of QtWebProcess. Honestly, creating a YAPA (Yet Another Public API) just for a test's sake sounded like overkill.

Finally, it is a good idea to test for pointer state (if it can be null) before calling into it.

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