Version: 3.5.2 (using KDE KDE 3.5.2) Installed from: Debian stable Packages OS: Linux I'm using HTML + XML (AJAX) to implement an online help system. The full text index used for full-text search is a fairly large XML file. My help search page loads the XML file asynchronously, which should mean that scripts aren't running while it's loading. But the file takes longer than Konqueror's very conservative time limit to load, and I get the annoying warning dialog "A script on this page is causing KHTML to freeze, blah blah blah...Abort or Continue?". If you hit "continue" everything works as expected. But since this is happening due to a long XMLHttpRequest, there isn't any JS code for me to trim or optimize--I fire off the request, and the warning appears before I even get a chance to execute anything else. A couple of issues are at work here: 1) Why does KHTML think the script is blocking when it's loading asynchronously? Shouldn't it send the XMLHttpRequest and then happily return to it's base state until it's done loading and the onreadystatechange fires? (I think my AJAX code is OK, because it works correctly in the other browsers I've tested--including Safari--but I can post it if it would be helpful.) Is there something different I can do with my XMLHttpRequest to make it load without triggering the warning? 2) If I can't make my XMLHttpRequest "immune" to the warning, is there a way to prevent it from the web page or a script? I know it's a long shot, as it would probably be construed as a security loophole, but I really don't want users to have to deal with this. If the user clicks continue, the data finishes loading almost immediately and the full-text search works perfectly. 3) I understand the importance of catching runaway scripts and giving the user a way to terminate them, but I would argue that Konqueror has overly restrictive defaults set currently. I would like to request that in future releases you make the default time limit for scripts somewhat longer. If the number of bugs filed involving this warning is any indication, it seems that the current defaults give too many false positives. IE and Mozilla both have similar runaway script detectors, but they have (IMO) more reasonable default threshholds, so they tend to be more accurate--if you see that warning in IE or Mozilla, it's usually because it really *is* a runaway script, not just because it's doing something intensive or loading a big file.
The default for warning is either 5 or 10 seconds, forgot which... so something else must be going wrong.. Any chance you could provide a testcase of some sort?
I'm afraid I don't follow your logic when you say "default is either 5 or 10 seconds... so something else must be going wrong". Five or even 10 seconds seems like an awfully short amount of time to allow before hitting the panic button. Again I'll point out the large number of KDE bugs of the form "web site xxx.yyy.zzz triggers KHTML freeze warning" as evidence that it is too short and should be lengthened. I'll see if I can put together a minimal test case, but the XML file that triggers the problem is almost 9MB, so it will be a big attachment. Hope that's OK. Just out of curiosity, is that 5s or 10s a setting that the user can change? I poked around the Konqueror settings dialog and didn't see anything there. Maybe it's buried in some config file somewhere? (Sorry, in case you couldn't tell I'm not a full-time Linux hacker, just trying to make sure our stuff works on as many platforms as possible.)
I tried to upload a test case but the bug tracking system rejected the file because it's too large. If you want I can send it to an email address (it's about 4.5MB), or we can arrange something else. Let me know how you want to proceed.
Any chance gzip'ing it makes a difference?
And just in case: please keep in mind that this bug system is 100% public, so anyone can see any file you would upload.
Er, that 4.5MB file *is* zipped. Thanks for the reminder about it being a public site, but there's nothing in the test case that is private. Can I send it to you via YouSendIt or something like that?
I don't know what that is... My e-mail probably would bounce it, too, but if you want to, feel free to try (mo85@cornell.edu to skip a forwarding layer..)
hm i have no idea how to do a testcase for that, could anyone post a testcase in the bugtracker? thanks! would be great
no response, not testable.