First, the browser needs to be allowed to have codebase principal
support. To do this open a new tab, type in about:config. Navigate
the right colomn for "signed.applets.codebase_principal_support' and
set it to true.
Don't do that if you have Sun Java plugin installed as it compromises
your security. (And definitely you cannot expect it from your site
visitors). As I mentioned before XPConnect has nothing to do with Java
code despite it uses Netscape 4.x Capabilities security scheme as well
as the mechanics and methods/properties names - but all of this is
emulated by native browser code.
The posted code is tested OK under Windows 98 SE w/o any Java installed
(neither from Sun nor from Microsoft). My
signed.applets.codebase_principal_support is set on default false.
If it fails to work as it is check if you are using the latest FireFox
release. The mine is 1.0.7 / minor 1.7.12
Naturally it should ask for signed HTML page if loaded from server (?)
but no problem on local drive. I'm still in testing.
Second, the code needs to be modified slightly (at least I had to).
var fp =
Components.classes['(e-mail address removed)/filepicker;1'].createInstance(nsIFilePicker);
Not my fault, say thanks to Google Groups spam bot protection which
modified my code :-(
I confirm it must be only "single_quote at_sign mozilla dot org"
http://kb.mozillazine.org/NsIFilePicker
There seems to be quite a bit of information at the site. Never knew
it was there.
And you may notice that the code posted at that address is not working
due to the missing privilege request. Is it some kind of "allowance
code"? Thus if you know, you'll edit it, if you don't know it then it's
not for your usage (?)
In addition to a user needing to do the first step they will also need
to 'Allow' the permissions to be changed twice every time.
Unfortunately yes and I see it as XPConnect Group oops I'm going to
report. Netscape scheme implements two kinds of targets: Primitive
targets and Macro targets. The last serve as nodes for related
Primitive targets.
Say you can ask for UniversalFileRead and UniversalFileWrite (double
request using primitive targets) or UniversalFileAccess (single request
using macro target).
But in order to use XPConnect interfaces you need first request for the
newly introduced UniversalXPConnect privilege which is not included in
any macro target. You are not allowed to combine primitive targets in
new macro targets. So currently you need ask first for privilege to use
XPConnect (UniversalXPConnect) and then ask for privilege to make it
anyhow usable (say UniversaFileRead). IMHO it doesn't have too much of
sense and UniversalXPConnect should be dropped. But right now it is as
it is.