It works. It's just that it's very very slow, because the JS code runs many loops, to     
find out the versions that apply to this program, and its components, etc.    
They should really use a database query instead of doing several O(n^2) loops in    
Javascript....   
   
The bug here might simply be a speed issue.   
With my verbose debug output I can't really check, but the question is how slow   
Konqueror is, compared to other browsers. Someone who has normal binaries of   
Konqueror-3.1-rc1, without debug output, should check and report back. 
 
If there's indeed a speed issue, then the next step is to profile this run and find out 
where most of the time is spent... 

Warning: I'm only running Konqueror 3.0.4, not 3.1-rc1.    While speed is an issue, there's a more serious problem.  While JavaScript is  running, Konqueror freezes completely.  There's no feedback to tell a user  it's busy doing something.  No menus or buttons work, if other windows are  brought to the front, they are not redrawn, etc.    See my later bug report #42707 on how I think a well-written piece of software  should behave in such circumstances.  Somebody else has the same problem in  bug #36914.  Although #422707 is listed as resolved, I don't believe the  resolution is satisfactory.      If a piece of software isn't responding at all to user input, isn't  redrawing exposed windows and there's no visible sign that something is going  on, most people won't wait 30 seconds before concluding it's broken.  I think  it will be very hard to find a "good" timeout value given the variety of  machine speeds and scripting requirements out there.  The popup is a bandaid solution.     Could you at least spin the toolbar cog image while the interpreter is running and allow the stop button to abort the script?  Can I also suggest you write "JavaScript running" in the status line, but in a way that text (perhaps maliciously) written to Window.status doesn't clobber it?  The area where the download progress bar appears may be a good spot.    Ideally, run the user interface in a spearate thread.  That way the user doesn't have to hunt for the window that is hanging the entire Konqueror application and stop it.  JavaScript that creates new windows can make it hard to find the culprit.     On the speed comaprison, although , Konqueror 3.0.4 takes at least 5 times as long to run the script as Mozilla 1.0 (Mozilla/5.0 (X11; U; Linux i686;  en-US; rv:1.0.0) Gecko/20020529).      Mozilla 1.0: 9 seconds     Konq 3.0.4:  48 seconds (5 times slower)  Sorry, for being so difficult.  I'd like to contribute to actually solving the problem, but I just don't have time (not even to download 3.1-rc1).  Hopefully the detailed bug report and suggestions help in some small way. 

I think the bugzilla login ate my formatting.  I'll try that again in the hope 
you can read it more easily... 
 
Warning: I'm only running Konqueror 3.0.4, not 3.1-rc1.   
   
While speed is an issue, there's a more serious problem.  While JavaScript is   
running, Konqueror freezes completely.  There's no feedback to tell a user   
it's busy doing something.  No menus or buttons work, if other windows are   
brought to the front, they are not redrawn, etc.   
   
See my later bug report #42707 on how I think a well-written piece of software   
should behave in such circumstances.  Somebody else has the same problem in   
bug #36914.  Although #422707 is listed as resolved, I don't believe the   
resolution is satisfactory.   
   
  If a piece of software isn't responding at all to user input, isn't   
redrawing exposed windows and there's no visible sign that something is going   
on, most people won't wait 30 seconds before concluding it's broken.  I think   
it will be very hard to find a "good" timeout value given the variety of   
machine speeds and scripting requirements out there.  The popup is a bandaid  
solution.  
   
  Could you at least spin the toolbar cog image while the interpreter is  
running and allow the stop button to abort the script?  Can I also suggest you  
write "JavaScript running" in the status line, but in a way that text (perhaps  
maliciously) written to Window.status doesn't clobber it?  The area where the  
download progress bar appears may be a good spot.  
  
  Ideally, run the user interface in a spearate thread.  That way the user  
doesn't have to hunt for the window that is hanging the entire Konqueror  
application and stop it.  JavaScript that creates new windows can make it hard  
to find the culprit.  
   
  On the speed comaprison, although , Konqueror 3.0.4 takes at least 5 times  
as long to run the script as Mozilla 1.0 (Mozilla/5.0 (X11; U; Linux i686;   
en-US; rv:1.0.0) Gecko/20020529).  
  
    Mozilla 1.0: 9 seconds  
    Konq 3.0.4:  48 seconds (5 times slower)  
  
Sorry, for being so difficult.  I'd like to contribute to actually solving the  
problem, but I just don't have time (not even to download 3.1-rc1).  Hopefully  
the detailed bug report and suggestions help in some small way.  

KDE 3.1rc1 takes about 7-9 sec on P-IV 2.4 GHz and yes Konquerors javascript runs a lot 
slower than Mozilla's. However KDE3.1 javascipt is some 30% faster than that of 3.0.x. 
 
Javascript doesn't run in a separate thread (don't know David/Harri opinion on this), but it 
does give you a possibility to abort the script after five seconds and repeats it after each 
ten seconds. 

using KDE 3.2 rc1

I got a javascript look warning window.

I've click 3 times on continue,... still hang...

when I click on break, the browser wake up and everything was fine.

maybe somebody would like to run it in a debugger.

Using cvs head I see no lag at all. Menu comes instant. P3 703 mhz.

*** This bug has been marked as a duplicate of 62785 ***