[Webkit-unassigned] [Bug 13913] New: FrameView::clear doesn't reset m_slowRepaintObjectCount leading to 'sticky' static background

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue May 29 16:00:38 PDT 2007


           Summary: FrameView::clear doesn't reset m_slowRepaintObjectCount
                    leading to 'sticky' static background
           Product: WebKit
           Version: 522+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: freyther at handhelds.org

While exploring static background handling on the Gdk port. I found the
following issue and I think it applies to all ports.

Behaviour: Visit a site with a non static background, e.g http://www.kde.org
move to developer.gnome.org/doc/API/2.0/gtk/GtkWidget.html which has a static
background and then go back. On going back the static background is temporarily
'deleted' from FrameView::clear but it gets reset by FraneView::layout due
useSlowRepaint() returning true.

The two backtraces should illustrate the behaviour:
#0  WebCore::ScrollView::setStaticBackground (this=0x12e5c980, flag=false) at
#1  0x0124b2c1 in WebCore::FrameView::clear (this=0x12e5c980) at
#2  0x0120e5e3 in WebCore::FrameLoader::clear (this=0x1301ea00,
clearWindowProperties=true) at ../../../WebCore/loader/FrameLoader.cpp:781
#3  0x01213615 in WebCore::FrameLoader::begin (this=0x1301ea00,
url=@0x1301eba0) at ../../../WebCore/loader/FrameLoader.cpp:841

And then on layout:
#0  WebCore::ScrollView::setStaticBackground (this=0x12e5c980, flag=true) at
#1  0x0124c73b in WebCore::FrameView::layout (this=0x12e5c980,
allowSubtree=true) at ../../../WebCore/page/FrameView.cpp:467
#2  0x01330328 in WebCore::FrameGdk::handleGdkEvent (this=0x12e56d30,
event=0xbfffd4c0) at ../../../WebCore/platform/gdk/FrameGdk.cpp:145

As you see on ::layout setStaicBackground(true) is getting called even if the
newly loaded page does not require it. This is due FrameViewPrivate::reset not
resetting m_slowRepaintObjectCount to zero. I can't judge what breaks when
setting m_slowRepaintObjectCount to zero on a reset, at least
ScrollView::setStaticBackground seems to have the 'right' value.

(Not creating a patch yet, I hope this gets reviewed anyway)

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

More information about the webkit-unassigned mailing list