I have this as well. The bug has been around pretty much since KDE 4.1 and as the submitter indicates, does not occur consistently. My guess would be that it is a flash problem occurring only with certain ads.

The version of flash installed on my system is: 10.0.22.87

Same here with flashplugin 10.0.32.18-1 (on ArchLinux).

I looked this a bit closer yesterday. Apparently, it comes from this code in the homepage of arstechnica:

<script type="text/javascript" src="http://arstechnica.com/mt-static/plugins/ArsTheme/scripts/da-1.5.js"></script>
    <script type="text/javascript">
      cnp.ad.dart.setSite("ars.dart");
      cnp.ad.dart.setZone('homepage');
      //cnp.ad.dart.addParameterString('');
      cnp.ad.dart.addParameterString('mtfIFPath=/mt-static/plugins/ArsTheme/ad-campaigns/doubleclick/');
      cnp.ad.emptyFrameSrc="http://arstechnica.com/mt-static/plugins/ArsTheme/scripts/empty.html";
      cnp.ad.loaderFrameSrc="http://arstechnica.com/mt-static/plugins/ArsTheme/scripts/ad-loader-frame.html";
    </script>

You can notice the use of "da-1.5.js" which seems to stand for "ad" and avoid the adblocker.
Anyway, I don't know why the page becomes gray but at least, if you add the following filtering rules to konqueror:
arstechnica.com/*/scripts/da-1.5.js
it seems to be a pretty good work-around to the problem.

For me, sometimes the problem occur very often (about 90% of pages), while at other times it is rare (about 10% of pages). So I think Jan-Willem could be right about the problem being related to certain ads. Note that when the problem does not occur, the ad appears a short time after the page is loaded; this is about the same delay as the between the page load and the gray page when the problem does occur.

I have Flash installed but also have plugins disabled except for certain sites and Ars is not on the exceptions list. So I think it's JavaScript rather than Flash that causes this problem. The problem no longer occurs when I disable JavaScript, however the site's functionality is reduced a lot then, so it's not a good workaround.

Bug 214848 seems to be a duplicate of this one.

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

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

*** This bug has been confirmed by popular vote. ***

SVN commit 1140104 by orlovich:

Heavily rework iframes, to better match behavior expected on the web, and
spec'd in HTML5. In particular:

1) [i]frames are always KHTMLParts, that are consistently navigated.
Based on previous commits, they can handle other mimetypes
via wrapping in img/embed/pre as appropriate

2) The initial document for the iframe is created synchronously.

3) Better handling for frame names, including dealing with renaming and the
like.

This fixes #191667 (which expects a document for plaintext), #159028
(ad script on cbc.ca redirecting to blank page, synchronous initial iframe creation),
#235652 similar on target.com, and most likely #193362
(some ad scripts on arstechnica.com; however I can't seem to hit them so I can't
confirm)

Techinically, I did:
- rename the high level requestObject overload (and requestFrame) to
loadObjectElement/loadFrameElement to make their difference from the
lower-level requestObject clear --- the two overloads were different
enough to be a readability issue
- factor out a whole bunch of code from processObjectRequest so we
can use it for creating the initial KHTMLPart for [i]frames
(some of the refactoring also fixes javascript: source frames)
- loadFrameElement now responsible for initial KHTMLPart creation using above
- processObjectRequest always uses the pre-created KHTMLPart and navigates
it for [i]frames; though it may still ask to save stuff and the like.
- comment a whole bunch of stuff
- iframe element does initial creation when inserted into document,
cleanup when removed. 

BUG:191667
BUG:159028
BUG:235652
CCBUG:193362


 M  +50 -5     html/html_baseimpl.cpp  
 M  +3 -0      html/html_baseimpl.h  
 M  +1 -1      html/html_objectimpl.cpp  
 M  +202 -140  khtml_part.cpp  
 M  +35 -6     khtml_part.h  
 M  +3 -0      khtmlpart_p.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1140104

I've tested this patch couple of days and no more dart frame ;-D