I am seeing this same bug with the website http://open-eyes.org/ - but I have provided a clear testcase for it. As far as I can tell, since KDE 3.2, Konqueror can no longer properly render column-based framesets where the frameborder attribute is set to 0. http://open-eyes.org/ is a site I visit regularly (it's my site) and Konqueror had always rendered it correctly - until I upgraded to KDE 3.2 a few days ago.

Now when I resize the browser horizontally, it seems that the rightmost frame (the navigation bar) is not being repainted properly. It's not shifting over as it should be.  It actually *is* getting repainted, but it's always repainted in the same place relative to the left side of the browser window, whereas it should be shifting from side to side according to the right side of the browser window.

I'll attach a test case (it's in three files, since it's a frameset). Specifically, the bug appears when you have a frameset of the form:

<frameset cols="*,N" frameborder="0">
	<frame src="...">
	<frame src="...">
</frameset>

where N is some integer.

Created attachment 4606 [details]
Simple frameset that exhibits this problem

Make sure to download all three HTML files into the same directory before
trying this out. Then point your browser to frameset.html.

Created attachment 4607 [details]
Left frame in frameset

Created attachment 4608 [details]
Right frame in frameset

*** Bug 70241 has been marked as a duplicate of this bug. ***

CVS commit by mueller: 

yeah, sometimes one optimisation is just one too much. 
CCMAIL:74123-done@bugs.kde.org


  M +6 -10     khtmlview.cpp   1.619


--- kdelibs/khtml/khtmlview.cpp  #1.618:1.619
@@ -469,10 +469,9 @@ void KHTMLView::drawContents( QPainter *
 #endif
 
-//     kdDebug( 6000 ) << "drawContents this="<< this <<" x=" << ex << ",y=" << ey << ",w=" << ew << ",h=" << eh << endl;
+    //kdDebug( 6000 ) << "drawContents this="<< this <<" x=" << ex << ",y=" << ey << ",w=" << ew << ",h=" << eh << endl;
     if(!m_part || !m_part->xmlDocImpl() || !m_part->xmlDocImpl()->renderer()) {
         p->fillRect(ex, ey, ew, eh, palette().active().brush(QColorGroup::Base));
         return;
     }
-//    QRect dbg_paint_rect(ex,ey,ew,eh);
 
     QPoint pt = contentsToViewport(QPoint(ex, ey));
@@ -491,6 +490,11 @@ void KHTMLView::drawContents( QPainter *
         }
     }
+
+#if 0
+    // this is commonly the case with framesets. we still do
+    // want to paint them, otherwise the widgets don't get placed.
     if (cr.isEmpty())
         return;
+#endif
 
 #ifndef DEBUG_NO_PAINT_BUFFER
@@ -518,11 +522,4 @@ void KHTMLView::drawContents( QPainter *
             d->tp->fillRect(ex, ey+py, ew, ph, palette().active().brush(QColorGroup::Base));
             m_part->xmlDocImpl()->renderer()->layer()->paint(d->tp, QRect(ex, ey+py, ew, ph));
-#ifdef BOX_DEBUG
-            if (m_part->xmlDocImpl()->focusNode())
-            {
-                d->tp->setBrush(Qt::NoBrush);
-                d->tp->drawRect(m_part->xmlDocImpl()->focusNode()->getRect());
-            }
-#endif
             d->tp->end();
 
@@ -1824,5 +1821,4 @@ void KHTMLView::paint(QPainter *p, const
 void KHTMLView::useSlowRepaints()
 {
-    kdDebug(0) << "slow repaints requested" << endl;
     d->useSlowRepaints = true;
     setStaticBackground(true);

Will this be backported to the 3.2 branch?

it already is

I've also seen this behavior with some form elements - like textarea and selectboxes (I think). I can't tell if your patch also applies to those.

This only began in 3.2, it wasn't there in the first beta (I'm not sure about the second). And Konqueror actually seems to be a bit slower now as well. Complex CSS with lots of form elements can drag the speed down, as well as give the mentioned 'desktop showing through'.