nsIJSSubScriptLoader question

[marffin]

hi, I'm trying to use nsIJSSubScriptLoader to support plugins to my
extension. But it keeps giving me this error:

Error opening input stream (invalid filename?)

I checked the filename, the path, the code, nothing is wrong. Can
somebody help me out here? Thanks

ps: I'm using Windows and I don't think it's the slash that have
caused this problem

[Gijs Kruitbosch]

You know that you have to pass a URL rather than a path, right?

~ Gijs

[Michael Vincent van Rantwijk, MultiZilla]

And where is the failing source code? That would have made it a lot
easier to help you ;)

Michael

[marffin]

On Oct 12, 12:44 am, "Michael Vincent van Rantwijk, MultiZilla"

here is the code:

try{
var script = Components.classes["@mozilla.org/moz/jssubscript-loader;
1"].getService(Components.interfaces.mozIJSSubScriptLoader);
script.loadSubScript("file://C:\Documents and Settings\Sycre\plugin
\fastdial.js");
} catch(e)
{
dump(typeof e + ": " + e + "\n");
}

I tried to replace all '\' with '/' but it still didn't work. Under
what circumstances would loadSubScript fail?

[Gijs Kruitbosch]

You need forward slashes, it's a URL. Furthermore, you need to escape spaces
(%20). It's a URL like any other, and in this way it won't work.

An alternative way to do things is to initialize an nsIFile instance with the
normal windows path (keep in mind that in JS, you'd have to escape backslashes)
and then use getURLSpecFromFile from the nsIFileProtocolHandler .

Hope that helps.
~ Gijs

[white...@fastmail.us]

If using the nsiFile, doesn't the OP still need to escape the backslashes?

[Gijs Kruitbosch]

That's what I tried to say... I suppose the "in JS" bit may have made it unclear
- my point was that whenever you're in JS, you will have to escape those
backslashes (regardless of whether or not you're sending them to something on
nsIFile or something else).

~ Gijs

[marffin]

On Oct 13, 1:25 am, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote:

thank you very much, this helped A LOT!

[Mook]

Gijs Kruitbosch wrote:
> An alternative way to do things is to initialize an nsIFile instance
> with the normal windows path (keep in mind that in JS, you'd have to
> escape backslashes) and then use getURLSpecFromFile from the
> nsIFileProtocolHandler .
>

I thought touching protocol handlers directly were bad (or was that just
creating URLs?), and nsIIOService::newFileURI should be used for this
instead?

--
Mook

[Gijs Kruitbosch]

Mook wrote:
> Gijs Kruitbosch wrote:
>> An alternative way to do things is to initialize an nsIFile instance
>> with the normal windows path (keep in mind that in JS, you'd have to
>> escape backslashes) and then use getURLSpecFromFile from the
>> nsIFileProtocolHandler .
>>
> I thought touching protocol handlers directly were bad (or was that just
> creating URLs?),

I never heard about that, but that may be the case. Ask someone else. :-)

> and nsIIOService::newFileURI should be used for this
> instead?

That just calls the protocol handler directly:

http://mxr.mozilla.org/seamonkey/source/netwerk/base/src/nsIOService.cpp#504

I'm not sure why the extra level of XPCOM slowness (which may be limited when
we're not crossing XPConnect extra times, but still) would be preferable. But
maybe I'm missing something.

Anyway, this method has moved around several times... it used to be on
nsIIOService named in the same way it is on the file protocol handler now, but
that was changed. Whenever I have to look this stuff up, I check ChatZilla as
that's where I work, usually:

http://mxr.mozilla.org/seamonkey/source/extensions/irc/js/lib/utils.js#1032

Which is why I gave the OP the answer I did. As usual, there are various ways of
doing this...

~ Gijs