Java Applets in XUL

Java applets from a extension directly embedded in a XUL document (via a HTML-Namespace) seem to be a difficult thing to achieve. They are not only close to impossible to reference (Java plugin obviously doesn’t know chrome://-URIs) but also seem to be restricted to 300x300px. Not good. As our project depends strongly on data exchange between an applet and XUL code I searched the dark alleys of old forum entries and found a different approach yesterday and implemented it:

  • The applet is embedded not in XUL but in a HTML page that is contained in an iframe
  • The applet may access the embedding HTML by mayscript parameter
  • In HTML a script generates a custom DOMElement, puts the data to hand over to the extension JSONified in an attribute x and finally fires a custom Event A, which is bubbling up through all parent nodes, …
  • … until the listening extension captures this custom Event A. Data is read from the attribute x, handled and return values are written in another attribute y of said DOMElement. Then the extension itself fires another custom Event B from the Element.
  • The script in the HTML listens to Event B, and — when fired — reads the returned value from attribute y and passes it to the applet.

Easy, isn’t it?

So much hoops to jump through to solve such a seemingly simple task! And that only because the Java / Firefox bridges are mostly ropeways…

Communication between HTML and extension works so far, source code will be posted tomorrow. When I finished tackling the applet-to-HTML-thingy I will update, promised.

Aspects of Javascript

A problem that I come upon with Firefox Extension Development is that often it is close to impossible to find out, which object / function provided by Firefox is called when certain Events occur. For example: in spite of my all-day taking quest to find a central piece of code to detect changes of bookmarks I still don’t know exactly what functions are called when a Bookmark is created / deleted / changed1.

But thanks to Google and some Python background (Decorators) I found Beppu’s Decorator / AOP snippet for Javascript that is incredibly useful for finding out what exactly is happening without needing to alter Firefox’s source code2. This code allows to execute a script before or after some miscellaneous code is executed. Even wrapping a function is possible without any problem… check it out!

  1. note: this is not exactly true. There is the infamous DataSource "rdf:bookmarks" of Mozillas nsIRDFService. But recognizing exact acts seems to be too tedious to really start trying… So this approach stays my last resort! 

  2. doesn’t work for native XPCOM code, only for Javascript objects / functions. 

Catching the Acts – Firefox Extension Development

For a presentation at the workshop Web 2.0 and Social Software in Technology enhanced Learning at the DelFI 2007 I am currently knocking up a Firefox Extension, that aims at

  1. recognizing a search act (e.g. via Google)
  2. recognizing a bookmarking act and
  3. displaying the ratio between the number of aforementioned acts.

Should be straightforward, shouldn’t it? But noooo, there have been a few problems up to now. Firefox development is not a really easy task, current documentation is sparse, and debugging and building the extension can be a pain. Especially as there are so many ways to do things, it is hard to see the “right way”. As for the problems:

  1. Recognizing Search Acts: Actually this seems to be the easiest part: registering a listener at the onload-Event of the appcontent-Element should do the trick. As this part should be as extendable as possible, I plan a central Singleton, where other code may subscribe to this listener handing over a URL pattern (e.g. a regular expression). The Event is forwarded to the other code only if the pattern matches the called URL.
  2. Recognizing a Bookmarking Act: Difficult, difficult. I have a general idea how to do this, but as there are different ways of bookmarking (Ctrl+D vs. Drag’n’Drop) there doesn’t seem to be a central Observable that could be observed (at least in Firefox 2.x). The much-anticipated Places in Firefox 3 may solve this finally… My post in didn’t get any answers to this questions up to now, so either it is pretty easy or pretty difficult. Anyone any ideas?
  3. Displaying. There are so many ways of doing this I am just overwhelmed with possibilities… The 1M$-question is which one to decide on. We’ll see…

Apart from that my colleague Doreen (no blog yet!) and I try to bend our minds around communicating between JavaScript (Firefox) and Java. But that is a sad story for itself…

Starting to blog

Alright, so I have a blog now…

Every now and then I will write about technical stuff that I stumble upon while researching and working on my PhD project. My PhD will cover several different technologies and fields of research like

  • Firefox stuff
  • Java stuff
  • Scratching the rims of Information Retrieval
  • other interesting things

So, stay tuned…