[Webkit-unassigned] [Bug 31281] r50665 broke around 100 Qt layout tests

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from Andras Becsi <becsi.andras at stud.u-szeged.hu>  2009-11-10 07:43:38 PDT ---
(In reply to comment #2)
> Created an attachment (id=42860)
 --> (https://bugs.webkit.org/attachment.cgi?id=42860) [details]
> proposed patch
> 
> FrameView::FrameView() set initial value of m_canHaveScrollbars(true), but
> DumpRenderTree of Qt disable scrollbars by default:
> 
> WebKitTools/DumpRenderTree/qt/DumpRenderTree.cpp :
> 252        m_page->mainFrame()->setScrollBarPolicy(Qt::Horizontal,
> Qt::ScrollBarAlwaysOff);
> 253        m_page->mainFrame()->setScrollBarPolicy(Qt::Vertical,
> Qt::ScrollBarAlwaysOff);

Actually it is only set to ScrollBarAlwaysOff in the constructor of DRT (as
some kind of initial setting), and then reset if css or some change needs it,
so it is actually _not_ disabled. 
It does not change the failing tests if we remove this two lines from DRT.cpp.
The real problem is that the failing tests do not call
FrameView::updateCanHaveScrollbars() and that is why they fail. The question is
why update is not called.

> If we call updateCanHaveScrollbars(), it makes QtBuildBot happy. :)
> 
> Only we have only one problem: The new fast/overflow/scrollbar-restored.html
> won't work on Qt, because scrollbars are disabled by DumpRenderTree. After
> resizing scrollbars won't be appear if it is disabled ...
> 
> Should we enable scrollbars? It would make some tests fail ...
> Or should we skip only this new test?

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