Update January 17, 2011: The issue that I posted below had been resolved, thanks to the user’s feedback in the comments below. There are still some slowness of Java and OpenGL issues under Chrome and Safari, but I will publish a new blog post about those issues.
—————————–
After some updates on Chrome and Safari (or Java itself, I am not quite sure) happened within the last month, sketches viewed in Chrome and Safari started to have issues. I try to find a fix, however I couldn’t find a proper solution, so I am reaching out to you people to see if anyone has a solution. Below, I try to dictate the issue and the current temporary fix I am using on the website at the moment.
How it was before
On OpenProcessing I was using the <object> tag, which is defined by W3C as the tag to be used when loading Java applets. Every sketch on the site has its own folder (eg. /visuals/applets/visuale33893968dc725ff118fe73b6c3d41cc) so I was also using the codebase parameter to provide the directory that the sketch runs under. So when a sketch is using an image (eg. loadImage(“test.jpg”) ), java would look for the image on the codebase directory.
The html code looked like this:
<object classid="java:living.class"
type="application/x-java-applet"
codebase="../visuals/applets/visuale33893968dc725ff118fe73b6c3d41cc"
archive="living.jar,core.jar"
width="300" height="300"
standby="Loading Processing software..." >
<param name="archive" value="living.jar,core.jar" />
<param name="codebase" value="../visuals/applets/visuale33893968dc725ff118fe73b6c3d41cc/">
</object>
The problem: Chrome and Safari stopped supporting <object> tag.
Around mid-December, 2010, chrome and safari browsers stopped displaying java applets given with <object> tags. I was also informed about this issue on the feedback forum and couple of users recommended me to check out javadeploy.js, a javascript solution to curate the proper html code for displaying applet. This solution is also used by the Processing application itself when exporting sketches to html. After playing a little bit with it, I saw that this javascript creates an <applet> code (which is deprecated by W3C) instead of <object> tag, but sketches seemed to work fine across browsers (but extremely slow on Chrome and Safari). So I updated the site with this version. The javascript code looked like this:
var attributes = {
codebase: '../visuals/applets/visuale33893968dc725ff118fe73b6c3d41cc',
code: 'living.class',
archive: 'living.jar,living.jar,core.jar',
width: 300,
height: 300,
image: 'loading.gif'
};
var parameters = { };
var version = '1.5';
deployJava.runApplet(attributes, parameters, version);
HTML code that deployJava generates looked like this:
<applet codebase="../visuals/applets/visuale33893968dc725ff118fe73b6c3d41cc" code="living.class"
archive="living.jar,living.jar,core.jar" width="300" height="300" image="loading.gif">
<param name="codebase_lookup" value="false">
</applet>
After a week, I started receiving comments about sketches not loading external files (images, sound files, etc.). After some digging, I realized java applet was ignoring the codebase information, and wasn’t able to find the related files. This wasn’t becoming an issue when you check index.html file generated by Processing on export, since every file is in the same directory and there is no codebase information. However, it was becoming an issue when your uploaded sketch gets moved to its own directory under applets folder.
Current situation: <object> for Firefox 
but <applet> for Chrome, Safari 
Currently, I added the logic to check the browser of the user and display <applet> version for Chrome and Safari, and <object> version for the other browsers. So this only partially solves the problem. People using Chrome and Safari still can’t see the sketches using images, audio, or any external file.
For the moment I have to advise you to use Firefox when browsing OpenProcessing (I always found Firefox superior to others, but of course, I don’t support browser discrimination). You will see the sketches properly and fast. If you use Chrome or Safari, it will be slow, and any sketch using external files will break.
I would appreciate any comment, direction or help you can provide me on solving this issue. Please also keep me updated if you see errors and problems that might be related to this issue or related to the website in general. Only with your information and emails I can keep track of the user experience on the site. Please comment below, or shoot an email to 
.
