Bug 61222 - Konqueror doesn't wait for applet response
Summary: Konqueror doesn't wait for applet response
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: kjava (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-14 16:00 UTC by Elner Ribeiro
Modified: 2012-06-18 19:54 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elner Ribeiro 2003-07-14 16:00:58 UTC
Version:            (using KDE KDE 3.1.1)
Installed from:    SuSE RPMs
Compiler:          gcc 3.3 (prerelease) (SuSE Linux)
OS:          Linux

After load a Java applet and initialize it, if it requires a great amount of CPU time, Konqueror doesn't wait for applet response, returning to JavaScript, which mades the call, a wrong result ("undefined").
As an example, if applet function only returns after a great delay (+- 20 secs), result will be "undefined".
V.g.:

public class X extends Applet {
 ...
 public int test() {
  //produces a delay (great amount of CPU time to process)
  int j = 0;
  for (int i = 0; i < 2000000; i++)
   j++;
 }
}

A call to the function test(), made through JavaScript, returns "undefined".
All functions are correct, Java Console shows no problems and we still have a bad result.
Mozilla and Netscape Web Browsers produce the expected result.
Comment 1 Koos Vriezen 2003-07-16 17:30:22 UTC
Yes, kde-3.1.2 or newer has a timeout of 15 sec. I can fix this in CVS head, but not in the 3.1 
branch I'm afraid. Reason is that konqueror blocks on js->java calls and without a timeout, we 
could have a hanging konqueror. 
Comment 2 Koos Vriezen 2003-07-30 21:09:11 UTC
Btw, I think you better solve these cases with a polling approach like: 
 public class X extends Applet { 
    Thread thread = null; 
    WhatEver result = null;  
 ...  
 public int test() { 
   thread = new Thread(){ 
     void run() {  
       //produces a delay (great amount of CPU time to process)  
       int j = 0;  
       for (int i = 0; i < 2000000; i++)  
         j++; 
       //ready 
       result = whatever; 
       thread = null;  
     } 
  }; 
  thread.start(); 
 } 
 boolean isReady() { return thread == null; } 
 WhatEver getResult() { return whatever; } 
}  
 
And in javascript you could do: 
  function checkDone() { 
    if (myapplet.isReady()) 
      .... // handle whatever result 
    else 
      setTimeout("checkDone()", 500); // check every 500ms if ready 
  }   
  myapplet.test(); 
  setTimeout("checkDone()", 500); // after 500ms if ready 
 
I think this works also better in netscape/ie because you don't block the browser 
Comment 3 Mark Riordan 2004-09-03 22:47:05 UTC
I would appreciate it if the 15 second timeout were removed.
That would allow compatibility with the majority of other browsers.
I was just about to submit a bug (wish) on this myself.
I have a simple applet that demonstrates with (with Java source as well) at this site:

http://people.stdnet.com/mark/konq/LongRunningApplet.htm

When appending to MY.INI, first add a blank line, in case the file does not end with CRLF.

In my case, it's not a matter of the applet taking 15 seconds of CPU time--it's waiting for a user response.  It would be awkward to have to recode my large applet to account for Konqueror's behavior.  Thanks.
Comment 4 Mark Riordan 2004-09-03 22:56:00 UTC
Whoops, ignore that remark about MY.INI.  Sorry--pasted from the wrong buffer!
Comment 5 Koos Vriezen 2004-09-04 22:08:06 UTC
Yeah, that should be done indeed.
The problem is that currently the only way to hold the javascript interpreter, while still be able to have an interactive browser, is to start a local event loop. Local event loops are dangerous and leed to all kinds of crashes if events are not carefully filtered. In Qt4, we might have a better way to solve this. Eg. by running kjs in a separate thread. Currently is that impossible because entering the Qt framework, deadlocks if already in some signal handler (eg the html tokenizer needs result of a javascript eval).

Btw, I mentioned the polling above. A other way could be to let Java call a javascript function when it's done processing. Look at netscape.javascript.JSObject for that. I'm not saying that you should use this, it's just another way of doing this.
Comment 6 Mark Riordan 2004-09-06 15:55:13 UTC
Koos Vriezen,

Thank you for your reply and suggestion.

Mark R
----- Original Message ----- 
From: "Koos Vriezen" <koos.vriezen@xs4all.nl>
To: <mark@stdnet.com>
Sent: Saturday, September 04, 2004 3:08 PM
Subject: [Bug 61222] Konqueror doesn't wait for applet response


> ------- You are receiving this mail because: -------
> You are a voter for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=61222
> koos.vriezen xs4all nl changed:
>
>            What    |Removed                     |Added
> --------------------------------------------------------------------------
--
>              Status|UNCONFIRMED                 |NEW
>       everconfirmed|0                           |1
>
>
>
> ------- Additional Comments From koos.vriezen xs4all nl  2004-09-04
22:08 -------
> Yeah, that should be done indeed.
> The problem is that currently the only way to hold the javascript
interpreter, while still be able to have an interactive browser, is to start
a local event loop. Local event loops are dangerous and leed to all kinds of
crashes if events are not carefully filtered. In Qt4, we might have a better
way to solve this. Eg. by running kjs in a separate thread. Currently is
that impossible because entering the Qt framework, deadlocks if already in
some signal handler (eg the html tokenizer needs result of a javascript
eval).
>
> Btw, I mentioned the polling above. A other way could be to let Java call
a javascript function when it's done processing. Look at
netscape.javascript.JSObject for that. I'm not saying that you should use
this, it's just another way of doing this.

Comment 7 Myriam Schweingruber 2012-06-18 19:54:41 UTC
Message from the Bugsquad and Konqueror teams:
This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore.
If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report.
Thank you for your understanding.