My co-woker Chris had the onerous task of designing an entire point of sale web-application from rather thin functional requirements on a very short deadline. I had the seemingly small and straight-forward task of printing the receipt and opening the cash drawer. Seemingly straight-forward, but it turns out to be quite a pain in the ass to print from a web-app. Without using some sort of applet (Java or ActiveX) printing directly to the printer without going through the brower's print mechanism is pretty much impossible. To operate the cash drawer I needed to be able to send a specifc set of bytes to the drawer unmolested... I had to do it without having a user to click "OK" on a print dialog every time. So an applet it is. But we wanted good CSS support, which more or less rules out IE, and for the most part rules out ActiveX... which for all it's warts has a porous enough security model to allow printing without much hassle. That left printing from a Java applet. To print from a Java applet means running outside the sandbox in a signed java applet. This helpful example shows how to get it done... almost. The problem is that with modern Mozilla builds, Javascript calls to an applet are untrusted. Even signed javasript calls to a signed java applet are untrusted, and there appears to be no way to bridge that gap. The end result is that even though you went through the effort of signing your applet, method calls triggered from Javascript are unsigned. Hello: Security Exception. But writing shitty code seems to be my calling, and here's my work around: Threads. Unfortunately a thread created from an untrusted method call is also untrusted. Ok, I'll just have a waiting thread created during the applet's init() and use thread.notify() to spur it into action. Nope. The notify() call requires additional security rights too. What I eventually did, was to create a thread which every so many milliseconds tests the value of a boolean. The untrusted method call flips this bit, and the thread takes it from there. Since the thread was created during the init() phase, it retains the additional security granted to the signed applet. The printing is handled by writing to a file... in this case "LPT1:" That was the easy part I figured out in about 15 minutes after getting the task. It was about 2 months later and a day before the deadline that I got around to starting the applet part. *sigh* Nothing like a deadling to make things happen.