UPDATE: This code has not been seriously audited for security holes, and may introduce vulnerabilities. Also, when I wrote it I did not take into account work on Gecko 1.9. Please be aware this code has not gone through rigourous testing.
Several months ago, I came around with a question: how should I send information from a content page to chrome. I wasn’t able to do it by DOM events as bz suggested, so when I did a little thinking, I came up with a solution for ManyOne Networks, Inc., my employer, that I wasn’t able to talk about at the time.
That time has passed. Regretfully, ManyOne has decided not to release the product I was working on, but they’ve no qualms about releasing the source code behind it. Including my special message-passing code.
dust-source.tar.bz2 > components/mnIChromeMessenger.idl and components/mnChromeMessenger.js .
How a webpage uses it:
- You create a JS-based object containing all the data you want passed upstairs.
- You include a window property, which is the
topwindow you can reach.
- You wrap this object in another JS object (which I refer to as
wrapper), as its wrappedJSObject:
This does some minor sanity-checking on the wrapped object (basically, making sure all but a couple properties are numbers, strings, boolean or undefined), and then dispatches a message to Mozilla’s observer service, with a topic of “content-message”.
Now, it’s entirely up to the chrome and XPCOM code to write observers to listen for this particular topic of message. One idea we had was to use this for opening new tabs by script. You’ll find in the tarball’s chrome/portlets/content/navigatorOverlay.js at line 448 a procedure by which we did this. There are some weaknesses in the scheme (notably, this code can’t be used to directly return a window object of the new browser to the caller, and there’s no concept of tabbrowser’s maximum tab count – thus inviting tabbrowser spam), but overall, it would do what we needed it to do.
Personally, I’d like to see mozilla.org review and adopt this code somewhere – say, in extensions/chrome-messenger, or perhaps in the toolkit if the Aviary or Firefox teams want it. I wrote this code for commercial use, and we tested it pretty thoroughly on our company’s product. It works beautifully.
I’m thinking seriously about submitting a bug to get this code checked in, but I’d like your feedback on where in the source it should live, and who wants this capability. If there’s not enough interest, then I won’t file a bug and we’ll just leave it on the sidelines, maybe as a XPI on addons.m.o.
P.S. This is my 300th blog entry. Nice coincidence that it should be a useful one.