| Summary: | frame inside frame recursion at blog of SAP manager makes Konqueror use insane amounts of memory and cpu time | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Martin Steigerwald <Martin> |
| Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | frank78ac, hnzekto |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Martin Steigerwald
2005-11-15 10:41:36 UTC
For the figure about memory consumption: I opened this blog another time to see if that behavior is reproducable. Before I did this it seemed, that the frame inside frame recursion had come to an end, Konqueror did not eat more memory - so it may well be that an internal frame inside frame limit in Konqueror has already been reached. Still I consider the amount of resources just for one opening of the blog already quite insane and as Mozilla Firefox and Opera do not show that behavior, there might well be a fixable bug hidden in Konqueror. At least the konqueror rendering is wrong (well, different to FF at least) - firefox doesn't open frames within frames on that page, while konqueror does. I didn't leave it long enough to see if it got to OOM. *** Bug 139011 has been marked as a duplicate of this bug. *** same problem here, try this one on the same site: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824 Konqueror renders frame after frame, nesting each one in the other, making the result an interesting work of art but resulting in a totally weird and unreadable UI clutter...,-) Opens fine in Firefox 2.0.0.3. I saved this page with Firefox using "Save page as/... Webpage, complete" to see what's going on. This <iframe>-recursion seems to be due to more than one problem (both in Konqueror and in the page itself; all I write here applies to Konqueror 3.5.8 and SVN trunk revision 798811).
The short version is:
1. Protection against recursive inclusion of <iframe>s fails if JavaScript (document.location.replace) is involved (Firefox stops after 10 recursions in this case).
2. The SAP webpage uses document.location.replace for the file in the <iframe>, not for the parent which was probably intended.
3. A regular expression check of parent.location.href fails in the file in the <iframe> in Konqueror, but apparently not in Firefox.
Here is the long version:
It seems that Konqueror actually has some protection against the inclusion of an HTML page in itself using <iframe> as can be seen in this example (save as recursive-iframe.html):
<html><head><title>konqi test</title></head>
<body>
<p>This is the top of a new HTML file.<p>
<p>An iframe starts below this line:</p>
<hr />
<iframe src="recursive-iframe.html" width="95%" height="95%">
</iframe>
</body>
</html>
The page is included just once, then the recursion stops (Firefox stops the recursion even earlier and doesn't include the file at all).
One of the problems in Konqueror is that this protection does not work if the <iframe> includes another HTML file which then replaces itself by the first HTML file using JavaScript (document.location.replace ()). To see this, save this file as recursive-iframe-2a.html:
<html><head><title>konqi test</title></head>
<body>
<p>This is the top of a new HTML file.<p>
<p>An iframe starts below this line:</p>
<hr />
<iframe src="recursive-iframe-2b.html" width="99%" height="99%"></iframe>
</body>
</html>
and this as recursive-iframe-2b.html:
<html><head><title>konqi test</title>
<script type="text/javascript" language="javascript">
document.location.replace('recursive-iframe-2a.html')
</script>
</head>
<body>
<p></p>
</body>
</html>
You get an infinite <iframe> recursion in Konqueror (Firefox stops after 10 recursions). This is essentially what happens when that SAP page is opened in Konqueror.
The situation in the SAP page is similar:
The HTML file contains an <iframe> (just like the example recursive-iframe-2a.html), and the included file contains in its <head> the following JavaScript code:
<script type="text/javascript" language="javascript">
try {
var pattern = /^https:\/\/(www(\d{3})?|wwwn|admin|webservice)\.sdn\.sap\.com/;
if (!pattern.test(parent.location.href)) {
document.location.replace('https://www.sdn.sap.com/irj/sdn/weblogs?blog='
+ escape(document.location.pathname)
+ escape(document.location.search));
}
} catch (e) { }
</script>
This is apparently a check that should make sure that the page is opened from the SAP webserver and not from some local copy. The mistake in the page is that it then uses 'document.location.replace ()' (instead of replacing the location of the parent) in case of failure, i.e., it replaces the contents of the <iframe> with the first HTML file which contains the <iframe>. This leads to the recursion, but only in Konqueror!
The strange thing is that the regular expression check (!pattern.test(parent.location.href)) fails in Konqueror (but apparently not in Firefox). It's not easy to analyse this with a local copy of the page because parent.location.href yields something different then. I can just say that parent.location.href yields the right offline URL if I use the local copy and that the regular expression check works OK if I replace 'parent.location.href' with the actual URL
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1700
My first guess would be that parent.location.href is for some reason not equal to this URL, but the easy check
document.write ("parent.location.href = " + parent.location.href);
requires write access to the file on the web server.
Wow, thanks for the phenomenal analysis. I am collecting a whole bunch of issues in this area ATM, and this is an angle I didn't think of... Thankfully testing the last bullet is much easier with a source build.. I am closing this, cause I can´t reproduce this with Konqueror from KDE SC 4.7.4 anymore, neither with webkit nor khtml. The page I mentioned just displays fine. Since I don´t see a fix targeted at this in the comments, I am closing this as "WORKSFORME". Feel free to reopen when there is still an issue left or adapt resolution to something else as you see fit. (First comment of mine with new Bugzilla;) |