[Webkit-unassigned] [Bug 150871] New: Wheel event callback removing the window causes crash in WebCore.

Tue Nov 3 16:50:44 PST 2015

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

            Bug ID: 150871
           Summary: Wheel event callback removing the window causes crash
                    in WebCore.
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Macintosh
                OS: Mac OS X 10.10
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore JavaScript
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: alexanderomara at gmail.com

In WebKit, if a window is removed while it is triggering a wheel event, it will crash on a bad memory access (example code and live demo below).

The crash is triggered in the WebCore/page/FrameView.cpp, in FrameView::wheelEvent, on what I believe is the delegatesScrolling() code.

However, the fault appears to lie with the function calling it.

WebCore/page/mac/EventHandlerMac.mm:
...
bool EventHandler::platformCompleteWheelEvent(const PlatformWheelEvent& wheelEvent, ContainerNode* scrollableContainer, ScrollableArea* scrollableArea)
{
    // We do another check on the frame view because the event handler can run JS which results in the frame getting destroyed.
    ASSERT(m_frame.view());
...

The only check against it being null appears to be an ASSERT call, which is not graceful and removed in release builds.

Compare this against a similar funtion:

WebCore/page/EventHandler.cpp
...
bool EventHandler::platformCompleteWheelEvent(const PlatformWheelEvent& event, ContainerNode*, ScrollableArea*)
{
    // We do another check on the frame view because the event handler can run JS which results in the frame getting destroyed.
    FrameView* view = m_frame.view();

    bool didHandleEvent = view ? view->wheelEvent(event) : false;
    m_isHandlingWheelEvent = false;
    return didHandleEvent;
}
...

This has a check against a null pointer, before calling the wheelEvent.

Currently, this can be seen affecting both the latest Nightly WebKit browser and Apple's Safari, as well as anything that links against the same libraries, such as those using WebView.

Additionally, I ran a test with pywebview, which I believe is using a legacy API for these libraries, and it crashes in WebCore/page/mac/EventHandlerMac.mm, on the EventHandler::platformCompletePlatformWidgetWheelEvent function.

Here is a live demo for how to trigger the crash:

https://cdn.rawgit.com/AlexanderOMara/49e10fcd48b0ab680c56/raw/5c131abd9a11a8f5b1a4534c8ceba2d23f515781/index.html

And the code from the link:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8" />
        <title>WebKit Wheel Event Remove Window Crash</title>
    </head>
    <body>
        <script type="text/javascript">
/*<!--*/
(function(window) {'use strict';

var iframe = window.document.createElement('iframe');
iframe.style.position = 'fixed';
iframe.style.left = iframe.style.top = '5%';
iframe.style.width = iframe.style.height = '90%';
window.document.body.appendChild(iframe);

function iframeReady() {
    iframe.contentWindow.document.body.innerHTML = '<h1>Wheel here to crash.</h1>';
    iframe.contentWindow.addEventListener('wheel', function() {
        // Removing the window during event firing causes crash.
        window.document.body.removeChild(iframe);
    });
}

var pollInterval;
var pollReady = function() {
    if (iframe.contentWindow.document.body) {
        window.clearInterval(pollInterval);
        iframeReady();
    }
};
pollInterval = window.setInterval(pollReady, 100);

})(window);
/*-->*/
        </script>
    </body>
</html>

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151104/0768027e/attachment-0001.html>