Bug 82090

Created attachment 6094 [details]
screenshot

Here is an example screenshot.

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

(From duplicate report)
Steps to reproduce: 
 
 1) I start konqueror and enter a page in the location bar (www.slashdot.org or news.google.com for example).  The tab bar is not showing, as there is only one page open. 
 
 2) I enter a second page in the location bar and use Ctrl+Enter to open the page in a new tab. 
 
 3) I return to the first page and scroll down. 
 
 Result: the new parts of the page are black - not painted at all.  When I mouse over links, parts of the page surrounding the link are repainted. 
 
 This renders the first tab mostly useless for me.  I will try setting the tab bar to always be displayed to see if that fixes it for me. 

Is that _really_ from 3.2.0/Mandrake rpms?
It sounds related to Zack's flicker fix on first tab spawning, but if it's not a CVS build like in #84218, then I don't get it at all...

I've seen this bug with 3.2-Branch konqueror.

I reported the duplicate.  FWIW, I see it every time with current CVS, but I have never seen it happen with 3.2.2 from Debian Sid.

FYI, this problem exists also in Kmail.  And I've had this problem since sometime in 3.1.  It's one of the reasons why I don't use Konqi as my browser.

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

what X driver do you use?

If you refer to bug 86890 then you might have refering your question to me. Well I am using 'ATI' drivers for a Radeon 9200SE card on Linux 2.6.8-rc3 using the KT400 driver. I am using XFree86 4.4 again (switched back) due to huge problems with Xorg that I had (switching from console back to X gave me an overall black screen and kept me caught in the console but then I wasn't able to switch back or further only solutions was reset). Using XFree86 solved all this again. Hope this helped.

I use Xvnc from the Debian vncserver package.

Created attachment 7075 [details]
Screenshot 2 for Illustration XVesa

Created attachment 7076 [details]
Screenshot 3 for Illustration XVesa

Stephen Kulow wrote:
> what X driver do you use?

I don't think it is driver related.  Here are the steps I just used to produce it, using cvs HEAD from yesterday (August 10, 2004):

1) In Konqueror's web browsing preferences, select 'Hide the tab bar when only one tab is open'. (This is IMPORTANT.  My workaround is to not select this.)
2) Enter http://bugs.kde.org/show_bug.cgi?id=82090 into the Location bar (or any other website that requires a vertical scroll bar) and hit enter.
3) Wait for the page to load.
4) Enter http://www.kde.org/ into the Location bar (or any other website) and hit Ctrl+Enter to open it in a new tab.
5) On the tab bar that just appeared, switch back to the first tab.
6) Scroll the page.

Actual result: newly uncovered areas of the page are black.
Expected result: the rest of the page is displayed.

Additional info: covering the affected area with some other window then moving that window away results in a correct repaint (the expected parts of the website are painted).

The bug goes way back with me - I was using 2.1 up until a few days ago but didn't look for a solution to this bug as I thought my KDE was just too old. I upgraded the whole system (from Debian stable to Debian testing - KDE 3.3.2) - and the bug is still here. It shows after some time, but not only in Konqueror, but also in KMail and Opera. Could it be X server related? Some buffer getting cleaned without applications knowing about it?

Workarounds:
- restarting application
- resizing the window repaints the area, but when you scroll you still get black areas
- selecting text shows it (repaints it)

The bug never shows with newly opened applications - it takes some time before it shows. 

I have seen this bug in KDE 3.3.2 and now in 3.4.  I have it set to not hide the tab bar when only one tab is present.  On 3.3.2, it seemed to occur after running Konqueror for a long time and after having lots of tabs opened and the Konqueror memory usage would be very high.  It seems to occur *much* faster in KDE 3.4.0.

Snapshot attached

Created attachment 10445 [details]
Picture showing the problem

If I run the mouse over the page, sometimes portions get fixed.

I have the same problem. Never noticed it up until 3.4.0. Using gentoo, qt 3.3.4, xorg 6.8.2, and the 1.0.7174 nvidia drivers. 

I have seen the same problem running on Solaris using Sun's X server (which is much older than Xorg - i.e. no Render, fontconfig, etc.)  I have seen this with KDE 3.4.0 and earlier versions as far back as I've been using Konqueror, probably at least since KDE 3.1.

After some more investigations I saw that this most of the time happens when having more than one TAB open (which occours faster), than browsing single windowed.

But - and here we go - I have seen this black window bug within other applications too, such as KOPETE IRC plugin inside the scrollwindow. So my closest guess here is that this problem is more QT widget related than Konqueror. It looks like the pictures moved in memory is getting totally wrong addresses after some time and the content simply craps out. Can it be a compiler bug ? I doubt so otherwise it would happen regulary.

When I see the problem it will draw the text or graphics if I cover the 
window with some other app and force it to redraw, or if I change to a 
different tab and change back.  I agree, though, that it looks like it 
might be in QT.

-Aaron

Bug 77023 is probably a dupe of this bug.

I still see this with KDE 3.5.

Happens quite frequently for me too - in fact, on this page while adding this comment :)  Sometimes the incorrectly rendered parts show parts of previously rendered pages instead of being just black.  I use tabs heavily here.  Just to add more fun to the mix: while playing about with this page when the bug occurred, I hovered over links at the top of the page (most repainted upon hover, but one didn't) for a bit then scrolled down again - and the problem went away, i.e. scrolling down gave me correctly rendered page - no reload, no covering up with other windows, no switching tabs.

Possibly relevant versions etc:
 - Debian's Xorg 6.9.0.dfsg.1-4
 - an ATI Radeon Mobility 7500.
 - the following extensions:
  BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS
  Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER
  MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY
  SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFIXES
  XFree86-Bigfont XFree86-DGA XFree86-DRI XFree86-Misc
  XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST
  XVideo

I can confirm that this bug is also in Konqueror 3.5.1

Confirmed on  Gentoo with KDE 3.5.1 mobility 9700, fglrx, x.org 7

It also applies to Kopete! Dont know how to reproduce.

gcc version 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)
CFLAGS="-O2 -march=pentium-m -pipe -mmmx -msse -msse2 -fomit-frame-pointer"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

Confirmed on 3.5.2 too
(otherwise the same system as the post above)

This bug has been nagging me for years now (don't ask why, but this is the first time I went to BKO though).

I can confirm that:
- It happened already in KDE 3.3 and still does with the latest 3.5 branches.
- It happens with our SuSE 9.3 system at work (that's not a vanilla system anymore, many libs have been installed in special --prefixes, but X etc. are still the original ones) as well as with several Gentoo versions, up to very recent ones.
- It happens mostly with Konqy or KMail windows which have been open for a looong time (I use suspend-to-disk with my notebook, and often leave these programs open over night on other computers).
- I *am* using tabbed browsing a lot (in fullscreen), but that's obviously not a precondition for the effects.  Also, the bug does not only appear on the first tab, and I could not yet find a way to reproduce it (except trying not to ;-P). :-(  (Of course I tried the abovementioned simple instructions, but that did not do it.)
- The bug is that scrolling a khtml view does not repaint the exposed regions correctly. Most of the time, the regions appear black, but sometimes, also older web page contents from that session appear.
- Restarting the program helps, as does pressing the wheel or Ctrl-D to open a new Konqueror window with the exact same tabs and history.

Sometimes I thought it was just my installation, but since the bug persists already for such a long time throughout KDE versions, I am now very happy that I found this report and added my comments.  It's really annoying actually.

OK, some more details as I have one tab showing that behavior again:
- It does *not* affect all tabs in the same Konq window.
- It does not affect tabs "by age": I have some old, session-managed tabs open which I did not use and which I can scroll freely.  However, a tab I used a lot (going back/forward in the history, submitting forms) shows the problem.
- This new tab works fine.
- Now the broken tab suddenly works again. :-(  Stupid randomness.  Before, the only thing visible in the black was a focused link, then I opened a new tab  for bugs.kde.org and switching back the effect was gone (there were some actions like scrolling involved in between unfortunately, since I did not expect the bug to disappear so quickly I was not too careful).

Don't follow what Hans said 100%, but it sounds very similar to my workaround.  Say you have two tabs open, and your tab bar looks something like this (get your fixed width fonts out, and bear with the '+'):

----------------------
| _____  _____       |
|/ foo \/ bar \   +  |

If tab "foo" gets the blackness problem, I click-and-drag on "foo", dragging it over to some empty space to the right (+) and dropping it, which has the effect of opening a new, identical tab and switching to it.  "foo" will now be fixed, and I can close the clone tab immediately and carry on.  This is simple and quick enough that I can just about forget about the bug.

I can confirm it happening with 3.5.2 as well. I got this bug also with 3.4 series. Using latest Gentoo Xorg, Intel i852/855GM (i915 DRI driver)
Doesn't seem to be graphic driver dependant, as it happens with KHTML only.

Occurs only from time to time, restarting konqueror fixes the problem

It definitely is not related to the X server either since I have seen this on KDE running on Solaris 8 as well, using Sun's X server.

Confirmed with Konq 3.5.4 on Xorg-7.1.1 (nvidia driver) using linux kernel 2.6.16-gentoo-r10 (SMP) on x86_64.  If it helps, I've got debug libraries installed and I could intentionally SIGSEGV (and/or attach gdb to) my Konq next time I see "the black" to generate a backtrace (and possibly even a corefile).

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

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

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

Has been happening on default kubuntu install.

I still suffer from this - my newest workarounds:
- when a Konqueror shows this annoying behaviour too much (i.e. in many tabs, all the time when scrolling), I simply press Ctrl-D to clone the whole window with all tabs and close the original window
- in KMail, I think it is enough to temporarily change the (IMAP) folder - note that switching to another message is *not* sufficient

Ah, BTW - I wonder if this is related:
If I scroll HTML views while they are partially covered by passive knotify popups (happens often with full-screen konqui) or by the "show desktop name on desktop switch" popup, the underlying part of the webpage is saved and restored, ignoring the scrolling that happened in between.  I.e. I get old contents back in those areas.

This is very similar to this general bug, where I often get black parts, but also wrong/old HTML pages.  E.g. sometimes, when I scroll very large HTML pages and the newly exposed parts are black only, I keep on scrolling and after a full height of black, I get the above contents again.

Please, anyone who knows where any kind of output caching behaviour is built into khtml - tell us, so that someone can try and find out what's wrong here!

In case that matters:  I usually use the scroll wheel of my mouse/touchpad to scroll.  (Just guessing what could be the difference between us and all those people who do not seem to suffer from this bug.  Maybe it's just the fact that we like to keep our konquerors open "forever", i.e. weeks, just opening/closing tabs all the time.)

I just noticed black parts in kpdf, too!
In contrast to khtml however, they disappeared by scrolling, instead of bringing more black/wrong contents.  Still, the behaviour has always been quite erratic, so it could be the exact same bug, which would mean that it is *not* a khtml bug at all.

Created attachment 22130 [details]
black parts appeared in kpdf

the middle part is OK because it was refreshed after ksnapshot hid

Even though it seems to happen with different computers and graphics cards, I am still not convinced that it's not X-server related.  I recently disabled the backing store in the "Device" section of my xorg.conf using

        Option      "Backingstore"  "false"

and until now, the problems are gone.

So maybe this bug is triggered by a combination of KDE/Qt/XOrg and graphics drivers/cards ("radeon" driver with a Radeon Mobility card right here); for example, the programmers of different components might have made different assumptions about the lifetime or use of the backing store?!

It would be cool if more people who have (had) this problem could confirm that disabling/enabling the backing store makes a difference.

If so, someone should reassign the bug and/or make X-knowing people like Matthias Ettrich aware of it.

I have had this problem on Kubuntu Hardy, with the closed source nVidia driver and KDE 3.5.9. I didn't have the problem, until I enabled backingstore (it was part of the settings that people recommended for better 2D performance). From that point on, I had problems with webpages becoming black when scrolling, seemingly at random. However I haven't seen this problem since I disabled the backingstore, after reading this bug report.

So yes, I can confirm that backingstore makes a difference with regards to this problem.

Looks as if this has been resolved in KDE 4 or by better graphics drivers. No reports for KDE 4 here. As KDE 3.5 is not maintained anymore, I'm closing this bug. Please report you think it should stay open.