Java Applet not working
A client noticed that one of our java applets wasn't working anymore. However, we are not able to tell what the problem is.

###Specs###
The webapp is <a href="http://www.tiparlo.com/">tiparlo</a>. It is used to record and organize spoken language and mainly used at schools to train language and store for evaluation later. The app consists of an HTML interface, which is managed by JavaScript. The sound playing and recording is done via an in-house developed <a href="http://www3.s3.olefa.com/soundrecorder/">java applet</a>. As you can see on the test-page, the applet itself is in a working state.

In tiparlo however, the applet (further called soundrecorder) doesn't have a preloaded sound file. Since tiparlo consists of multiple sound files, JavaScript tells soundrecorder what file to play. For instance, if you want foo.ogg to be played, javascript tells soundrecorder to play http://url/path/foo.ogg.

This worked for some years now but not anymore.

###Bugtracking###
The problem is that it *does* work under certain conditions. For instance, it works on our local dev-machines, and on our public test-env. It just ceased to work for our clients.

Working example: http://test.s2.olefa.com/cgi-bin/apps/tiparlo?projectid=3&mode=viewer  
Non-working example: http://www.ecoles-dudelange.lu/cgi-bin/apps/tiparlo?projectid=1594&mode=viewer

Some useful facts:  

- both examples are running on the same server  

- the java applet, the js code, the html parser and the source code are shared resources. Hence, both examples are running the exact same code

- the relevant files to the problem are: soundrecorder.js and jrecord.jar. The `play` command is in soundrecorder.js:line 112

###What we know so far

- Browsers react differently to the non-working example. Safari/Mac plays everything right. Safari/Win however freezes on play. Firefox 4 doesn't play anything at all. Firefox 3.5/Mac does everything right again. However Firefox3.5/Win doesn't play anything at all. IE9 has the same problem. Same goes for Chrome. Opera crashes outright and needs to be restarted. We haven't yet found a browser on linux that works on the non-working example. To clarify: the working example works with all browsers on all platforms, except for Safari/Win (meh)

-  We tried using the alternative server-url for our non-working example (webX.sX.olefa.com), which is similar to the working example. This attempt failed.

-  We tried using relative paths for soundrecorder (e.g. /path/foo.ogg).

-  We tried updating Java to the latest version.

-  We tried accessing the applet differently.

-  We had a similar problem 6 months ago, that was caused by a java update. We tried the non-working example on a VM with an older java-version. It works. However, we suspect that java alone is not the culprit here since the same java-version/browser works on the working example.

-  Soundrecorder only refuses to play files that are loaded dynamically via JS. If it loads a file on init, there is no bug.

Generally speaking, we can't find out why the exact same code running under the exact same conditions works on one site, but doesn't on the other.
Java Applet not working
===

A client noticed that one of our java applets wasn't working anymore. However, we are not able to tell what the problem is.

###Specs###
The webapp is <a href="http://www.tiparlo.com/">tiparlo</a>. It is used to record and organize spoken language and mainly used at schools to train language and store for evaluation later. The app consists of an HTML interface, which is managed by JavaScript. The sound playing and recording is done via an in-house developed <a href="http://www3.s3.olefa.com/soundrecorder/">java applet</a>. As you can see on the test-page, the applet itself is in a working state.

In tiparlo however, the applet (further called soundrecorder) doesn't have a preloaded sound file. Since tiparlo consists of multiple sound files, JavaScript tells soundrecorder what file to play. For instance, if you want foo.ogg to be played, javascript tells soundrecorder to play http://url/path/foo.ogg.

This worked for some years now but not anymore.

###Bugtracking###
The problem is that it *does* work under certain conditions. For instance, it works on our local dev-machines, and on our public test-env. It just ceased to work for our clients.

Working example: http://test.s2.olefa.com/cgi-bin/apps/tiparlo?projectid=3&mode=viewer  
Non-working example: http://www.ecoles-dudelange.lu/cgi-bin/apps/tiparlo?projectid=1594&mode=viewer

Some useful facts:  

- both examples are running on the same server  

- the java applet, the js code, the html parser and the source code are shared resources. Hence, both examples are running the exact same code

- the relevant files to the problem are: soundrecorder.js and jrecord.jar. The `play` command is in soundrecorder.js:line 112

###What we know so far

- Browsers react differently to the non-working example. Safari/Mac plays everything right. Safari/Win however freezes on play. Firefox 4 doesn't play anything at all. Firefox 3.5/Mac does everything right again. However Firefox3.5/Win doesn't play anything at all. IE9 has the same problem. Same goes for Chrome. Opera crashes outright and needs to be restarted. We haven't yet found a browser on linux that works on the non-working example. To clarify: the working example works with all browsers on all platforms, except for Safari/Win (meh)

-  We tried using the alternative server-url for our non-working example (webX.sX.olefa.com), which is similar to the working example. This attempt failed.

-  We tried using relative paths for soundrecorder (e.g. /path/foo.ogg).

-  We tried updating Java to the latest version.

-  We tried accessing the applet differently.

-  We had a similar problem 6 months ago, that was caused by a java update. We tried the non-working example on a VM with an older java-version. It works. However, we suspect that java alone is not the culprit here since the same java-version/browser works on the working example.

-  Soundrecorder only refuses to play files that are loaded dynamically via JS. If it loads a file on init, there is no bug.

Generally speaking, we can't find out why the exact same code running under the exact same conditions works on one site, but doesn't on the other.