Question

I have an issue with using InternetExplorer6 as client to a TWiki site hosted on a RedHat9 server. Most of the time, when one clicks "preview changes" IE starts pulling 100% (as if it does a BusyWait for something in its bad code somewhere) and stalls completely. Sometimes it can be aborted and if I retry a couple of times it may get through - then the same problem appears on a "save changes" click.

Some problem not encountered with Mozilla. The IE flaw, hoever, has never been encountered on any other sites. Whereas this must, of course, be some IE seizure, it is important that the most widely used browser can be used with TWiki.

Feel free to reproduce the problem in http://retrograde.dk/twiki/bin/view/Sandbox/WebHome

Can anyone confirm this problem or suggest a workaround?

Environment

-- TWikiGuest - 19 Nov 2003

Answer

Lots of people use IE6 with TWiki, including myself with TWiki.org and http://donkin.org/ - I've never seen this issue. One related issue is when TWiki.org is severely overloaded (and most likely the CGI Perl scripts are hanging due to lack of CPU/memory on the server) and Preview appears to hang, but the 100% CPU on IE6 indicates a browser issue.

Does this happen with other TWiki sites, or only with your site? This might be something to do with IncreasinglyPoorPerformance and SaveForever, but it might be unrelated.

If you aren't using the default skin, try using that. Also, try turning off JavaScript temporarily.

Do you have any proxies, perhaps transparent ones? If so, try to bypass them.

Also, put tcpdump on the server ethernet interface, monitoring http traffic into a log file, and perhaps all TCP/UDP traffic directed to the server, to see if something odd is happening (e.g. packets getting lost and not re-sent for a long time). Normally, TCP hides any lost packets pretty well. Running top and trying suggestions at IncreasinglyPoorPerformance might also help.

However, since it is browser specific, it's most likely to do with the specific HTML/JavaScript involved with your site, rather than a server side issue.

-- RichardDonkin - 27 Nov 2003

Hi; thanks for the response.

I agree it has to be a browser issue - no webpage should of course be able to make a browser pull 100% CPU and effectively freeze the system. But it does (and not only when browsing from my machine) and this is a serious obstacle even if not really TWiki's fault. As you may imagine, people are not always too thrilled to get the response from me "well, just use Mozilla instead". :|

The site in question is a "virgin" TWiki installation without plugins. There are no proxies of any sorts inbetween (including transparent ones), but the one thing I can say is perhaps particular to my installation (other TWiki sites, such as this one, do work correctly, except I often experience the SaveForever problem here) is the fact that it is quite slow (indeed I was somewhat surprised at how slow TWiki runs there - probably due to spawning perl+rcs from Apache). It is running on a relatively small machine so TWiki responses are always rather sluggish, and this issue seems to be related to this.

However, since I have never experienced the problem on any other web sites it has to be something with the way TWiki produces responses - maybe an HTTP header field that IE likes to see quickly or some such thing. :7

-- MadsTroest - 02 Dec 2003