My tests prove I can feed JS strings through a XPCOM service, a special protocol handler and a corresponding nsIChannel implementation into the browser. Most of it was heavily inspired by the data: protocol handler and channel implementation.
The only detail left unresolved is the handling of hash targets for XBL… a crucial weakness. (I’ve gotten HTML hash targets working.) The hash targets are part of the URL, but they’re not getting recognized. This makes the protocol slightly better than data:.
There has to be some way to make this work. I just have no idea what it is. I’ve not seen any evidence of it in the protocol / channel pairs.
UPDATE: As far as I can tell, the problem is actually upstream of my code. My onStartRequest() and onDataAvailable methods get called normally, but my onStopRequest() doesn’t get called until I decide to move on to another page or close the window. The HTML page through my virtual: protocol does call onStopRequest with a status of 0. So this is probably something nutty in XBL.
UPDATE 2 Nope, it landed squarely back in my face. I’d filed bug 306217, and debugging led bz, biesi and I through a long series of hoops. Eventually, biesi guessed (correctly) that I should’ve closed the output stream.
But with that fixed, I can declare my virtual: protocol handler operational. Not optimal, but operational.