Summary: | Borken javascript at cbc.ca website causing redirect | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Troy Unrau <troy> |
Component: | khtml | Assignee: | Maksim Orlovich <maksim> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | multescugeorge |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Mandriva RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Troy Unrau
2008-03-09 16:44:43 UTC
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 |