[Webkit-unassigned] [Bug 40102] [Qt] editing/input/page-up-down-scrolls.html failure

[bugzilla-daemon at webkit.org]

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


Robert Hogan <robert at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robert at webkit.org




--- Comment #6 from Robert Hogan <robert at webkit.org>  2010-06-13 04:52:45 PST ---
This is failing because WebCore 'cheats' by firing the onLoad event before the FrameView has performed its final layout(). This is deliberate on the part of WebCore, from implicitClose() in Document.cpp (1862):

    // Make sure both the initial layout and reflow happen after the onload
    // fires. This will improve onload scores, and other browsers do it.
    // If they wanna cheat, we can too. -dwh

So at first glance you'd think Qt needs to ensure that it forces the layout before acting on onLoad events that need to know the correct layout, which is presumably what other ports do.

In the case of this test, QWebPagePrivate::handleScrolling() could always check that the layout is final before doing anything - but that's just one possible situation.

Qt doesn't know it's acting on an onLoad event so there doesn't appear to be a way of doing this in a generic that way will cover all cases.

This also seems to me like something WebCore should be looking after anyway - since it's the one that's 'cheating'. 

That said, I've no idea why this only fails for Qt - maybe it's something to do the way it queues events.

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