virtual: It works (completely)

After two very long days of coding and one bug patch, I’ve almost succeeded in the third approach to the string contents as files problem.

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.

One thought on “virtual: It works (completely)”

  1. I wouldn’t have expected the protocol to have any info on the # target. The # is simply used to identify a part of the data retrieved through the protocol.

Comments are closed.