Bug 33050 - [GTK] ASSERTs on fast/inline/inline-body-with-scrollbar-crash.html
Summary: [GTK] ASSERTs on fast/inline/inline-body-with-scrollbar-crash.html
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks:
 
Reported: 2009-12-30 04:44 PST by Gustavo Noronha (kov)
Modified: 2011-02-08 12:33 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gustavo Noronha (kov) 2009-12-30 04:44:26 PST
I have investigate this to find out that the problem lies on readjusting the size of the view, here (FrameView.cpp::layout around line 679):

    if (!subtree && !toRenderView(root)->printing())
        adjustViewSize();

This ends up in a call to updateScrollbars, in GTK+, which ends up triggering a resize of the view (because the parent widget's scroll bars take up space), which requests a relayout. So the ASSERT ends up being hit:

    ASSERT(!root->needsLayout());

I have investigated a bunch of solutions, such as having our own implementation of ScrollView::setContentsSize, but I always end up in having to either reimplement almost all of the updateScrollbars logic, or triggering a relayout anyway. I feel like the call to updateScrollbars is correct, and that triggering the resize of the view is an expected outcome - so the assert would not be correct for GTK+ - but I am not sure enough, so I decided to open this bug report and request help/advice from layout/scrolling wizards.
Comment 1 Martin Robinson 2010-09-30 16:30:06 PDT
This seems to be passing locally (perhaps because of the scrollbar changes). I'll unskip it and close, reopening if there are any problems.
Comment 2 Martin Robinson 2011-02-08 12:33:03 PST
Unskipped and this doesn't appear to be an issue any longer. Closing.