Skip to main content

executeScript(String script) script length bug finally solved !

2 replies [Last post]
Joined: 2007-09-28
Points: 0

Hello all,

Many people have already reported a bug concerning executeScript command length. Some people said it couldn't exceed something like 1000 characters, others said 2000 ...

The problem was that the application (more precisely the thread associated to the the WebBrowser component) hangs.

I think I discovered the truth about this bug :)

The script's length can't be in one of the forbidden zones othewise the application will hang. This is a bug in the native IeEmbed.exe or jdic.dll.

These forbidden zones are 1000 to 1018 characters (both included), 2024 to 2042, 3048 to 3066 etc... every 1024 characters

999 < script.length() % 1024 < 1019

I think it is related to the 1024 buffer size allowed to the message sent to IeEmbed.exe. I didn't look deeply in the native code.

Anyway, I came up with this java code to avoid this bug. Hope it will be useful for other devs.

public String executeScript(String script){

if ( (1000 <= script.length() % 1024) &&
(script.length() % 1024) <= 1018) {

StringBuffer suffix = new StringBuffer();

for (int i = 0; i < 20; i++){

suffix.insert(0, script);
script = suffix.toString();


String returnString = webBrowser.executeScript(script);

return (returnString);

Message was edited by: penpen07

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-12-07
Points: 0

Yeah, I know this thread is a year old, but since I just ran into this problem, I'll share my findings.

The problem isn't exactly as described by penpen07 but it's close. It is a buffer issue within IeEmbed. Basically MsgServer::RecvData() fails to take into account the situation where the message boundary may straddle the 1024 buffer boundary. It doesn't recognize that the delimiter is present but split across 2 recv calls. So it waits forever for the delimiter to arrive and the Java client waits forever for a reply from the IeEmbed server. Hence we have a deadlock. Since the Java client is likely running on the event dispatch thread, the UI becomes unresponsive. However, you can still do things within the embedded browser and the CPU is normal since the 2 threads involved are in a wait state.

I have a fix for this but since JDIC is no longer supported, I'm not sure if the JDIC group is interested in it.

Joined: 2006-02-19
Points: 0

Thanks penpen, I've fallen victim to this a few times. It doesn't seem to be as bad as it once was (i think they did some mods in the last version), but it has happened a couple of times since then so I'll implement your change just to (hopefully) prevent it should it happen again in future.

Thanks again