[Webkit-unassigned] [Bug 54123] Assertion failure in BackingStore::BackingStore if new WebPage becomes active before receiving a size

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from Adam Roben (aroben) <aroben at apple.com>  2011-02-09 11:28:10 PST ---
It looks like we end up scheduling a display in the web process before the WebPage has received a size. The display is being scheduled at this point:

>	WebKit.dll!WebKit::DrawingAreaImpl::scheduleDisplay()  Line 334	C++
     WebKit.dll!WebKit::DrawingAreaImpl::setNeedsDisplay(const WebCore::IntRect & rect={...})  Line 87    C++
     WebKit.dll!WebKit::WebChromeClient::invalidateContentsAndWindow(const WebCore::IntRect & rect={...}, bool __formal=false)  Line 362 + 0x21 bytes    C++
     WebKit.dll!WebCore::Chrome::invalidateContentsAndWindow(const WebCore::IntRect & updateRect={...}, bool immediate=false)  Line 77 + 0x20 bytes    C++
     WebKit.dll!WebCore::FrameView::invalidateRect(const WebCore::IntRect & rect={...})  Line 316 + 0x2e bytes    C++
     WebKit.dll!WebCore::FrameView::invalidateScrollbarRect(WebCore::Scrollbar * scrollbar=0x022f8ab8, const WebCore::IntRect & rect={...})  Line 2012 + 0x17 bytes    C++
     WebKit.dll!WebCore::Scrollbar::invalidateRect(const WebCore::IntRect & rect={...})  Line 453 + 0x1d bytes    C++
     WebKit.dll!WebCore::Widget::invalidate()  Line 166 + 0x3a bytes    C++
     WebKit.dll!WebCore::Scrollbar::setEnabled(bool e=false)  Line 432    C++
     WebKit.dll!WebCore::ScrollView::updateScrollbars(const WebCore::IntSize & desiredOffset={...})  Line 555 + 0x38 bytes    C++
     WebKit.dll!WebCore::ScrollView::setScrollbarModes(WebCore::ScrollbarMode horizontalMode=ScrollbarAuto, WebCore::ScrollbarMode verticalMode=ScrollbarAlwaysOn, bool horizontalLock=false, bool verticalLock=false)  Line 161    C++
     WebKit.dll!WebCore::ScrollView::setVerticalScrollbarMode(WebCore::ScrollbarMode mode=ScrollbarAlwaysOn, bool lock=false)  Line 94 + 0x30 bytes    C++
     WebKit.dll!WebCore::FrameView::layout(bool allowSubtree=true)  Line 859    C++
     WebKit.dll!WebCore::FrameView::updateLayoutAndStyleIfNeededRecursive()  Line 2311    C++
     WebKit.dll!WebCore::FocusController::setActive(bool active=true)  Line 409    C++
     WebKit.dll!WebKit::WebPage::setActive(bool isActive=true)  Line 1061    C++
     WebKit.dll!CoreIPC::callMemberFunction<WebKit::WebPage,void (__thiscall WebKit::WebPage::*)(bool),bool>(const CoreIPC::Arguments1<bool> & args={...}, WebKit::WebPage * object=0x022fd148, void (bool)* function=0x10005d53)  Line 19 + 0x11 bytes    C++
     WebKit.dll!CoreIPC::handleMessage<Messages::WebPage::SetActive,WebKit::WebPage,void (__thiscall WebKit::WebPage::*)(bool)>(CoreIPC::ArgumentDecoder * argumentDecoder=0x0231d308, WebKit::WebPage * object=0x022fd148, void (bool)* function=0x10005d53)  Line 246 + 0x15 bytes    C++
     WebKit.dll!WebKit::WebPage::didReceiveWebPageMessage(CoreIPC::Connection * __formal=0x022be3a0, CoreIPC::MessageID messageID={...}, CoreIPC::ArgumentDecoder * arguments=0x0231d308)  Line 48 + 0x23 bytes    C++
     WebKit.dll!WebKit::WebPage::didReceiveMessage(CoreIPC::Connection * connection=0x022be3a0, CoreIPC::MessageID messageID={...}, CoreIPC::ArgumentDecoder * arguments=0x0231d308)  Line 1718    C++
     WebKit.dll!WebKit::WebProcess::didReceiveMessage(CoreIPC::Connection * connection=0x022be3a0, CoreIPC::MessageID messageID={...}, CoreIPC::ArgumentDecoder * arguments=0x0231d308)  Line 539    C++
     WebKit.dll!CoreIPC::Connection::dispatchMessages()  Line 450 + 0x31 bytes    C++
     WebKit.dll!MemberFunctionWorkItem0<CoreIPC::Connection>::execute()  Line 76 + 0x10 bytes    C++
     WebKit.dll!RunLoop::performWork()  Line 63 + 0x1a bytes    C++
     WebKit.dll!RunLoop::wndProc(HWND__ * hWnd=0x002f0a44, unsigned int message=1025, unsigned int wParam=36335296, long lParam=0)  Line 57    C++
     WebKit.dll!RunLoop::RunLoopWndProc(HWND__ * hWnd=0x002f0a44, unsigned int message=1025, unsigned int wParam=36335296, long lParam=0)  Line 39 + 0x18 bytes    C++
     user32.dll!_InternalCallWinProc at 20()  + 0x28 bytes    
     user32.dll!_UserCallWinProcCheckWow at 32()  + 0xb7 bytes    
     user32.dll!_DispatchMessageWorker at 8()  + 0xdc bytes    
     user32.dll!_DispatchMessageW at 4()  + 0xf bytes    
     WebKit.dll!RunLoop::run()  Line 73 + 0xc bytes    C++
     WebKit.dll!WebKit::WebProcessMain(const WebKit::CommandLine & commandLine={...})  Line 82    C++
     WebKit.dll!WebKitMain(const WebKit::CommandLine & commandLine={...})  Line 48 + 0x9 bytes    C++
     WebKit.dll!WebKitMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpstrCmdLine=0x0002114c, int nCmdShow=10)  Line 172 + 0x9 bytes    C++
     WebKit2WebProcess.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpstrCmdLine=0x0002114c, int nCmdShow=10)  Line 66 + 0x18 bytes    C++
     WebKit2WebProcess.exe!__tmainCRTStartup()  Line 589 + 0x1c bytes    C
     kernel32.dll!_BaseProcessStart at 4()  + 0x23 bytes    

I.e., the WebPage is becoming active, so invalidates its scrollbar, which is non-zero-sized due to this code in Scrollbar::Scrollbar:

    // FIXME: This is ugly and would not be necessary if we fix cross-platform code to actually query for
    // scrollbar thickness and use it when sizing scrollbars (rather than leaving one dimension of the scrollbar
    // alone when sizing).
    int thickness = m_theme->scrollbarThickness(controlSize);
    Widget::setFrameRect(IntRect(0, 0, thickness, thickness));

I think we should not schedule a display at all in this case, since the WebPage is zero-sized.

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