Bug 159028

The issue there was roughly this:

var iframe = document.createElement("iframe");
var doc;
if (iframe.contentDocument)
   doc = iframe.contentDocument;
else if (iframe.contentWindow)
   doc = iframe.contentWindow.document;
else
   doc = iframe.document;

doc.location.assign("foo");

Since the .src on the iframe was never set, we didn't 
actually begin loading, so all the tests failed 
(no part, no contentWindow/contentDocument);
and the last clause in there is wrong, since it refers 
to the main document.

Making the IFrameElementImpl ctor request the part immediately
work, but I am worried about onload events; plus a slightly 
buggy version of the page actually fixed the cnn.com election tracker
(and, mysteriously, the document loading thing in acid3),
hence I need to test more; it may be intertwined with load event stuff, too.

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

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