Thanks for your reply, I'll try to answer every question.
1) I found creation of .xpi quite simple, and that would be the easiest part
of this project. As far as I know, we shouldn't have to do here more than a
standard structure like for every xpi, which I've already learned.
2) In the manifest file of our xpi we need to register a component with an
interface to the Mozilla's XPCOM. The C part will be the hardest part of
this project, as far as I can tell from few days research.
2a) I feel very good in C, in C++ little less, but still I think I can
handle this job. Mozilla's tutorials for XPCOM components are written quite
good, the only thing is they need couple of changes to handle new interface.
Gecko 2.0 brings many of it.
2b) As we register our component, we'll be able to send <script> part to it,
even from a JS call, so if tclsh could be connected to this component too,
we could interpret this script.
3) XPCOM provides several classes and interfaces to interact with DOM. Just
it's includes. I haven't yet tested how this could work, but for now I see
no reason why it shouldn't. To handle DOM access from Tcl we should provide
separate library based on XPCOM, or that's the way I understand it for now.
I've tried to build the existing TclXPCOM library, but without success. This
is because some parts of XPCOM interface wen't from public to private and
inheritance of some classes isn't valid for this reason. But TclXPCOM have
been made over 8 years ago and no updates from then were seen, so it's only
natural that it isn't working out of hand.
Some information could be taken from pyxpcom or javaxpcom as they seem to do
similar things with python and java.
I'll do some more research to look closer to communication through XPCOM