Hi Boris,
> Correct. I don't have a document to link to offhand, but you can take a
> build in which signed.applets.codebase_principal_support is enabled, go
> to a page that asks for UniversalXPConnect, allow the privilege and tell
> the browser to remember it. Then quit the browser and look at the
> resulting capability.policy prefs in user.js in your profile.
Ok, I see. I've already tried this and it does not work.
Even having the capabilities added to your prefs.js file, which adds the
following entries:
user_pref("capability.principal.codebase.p1.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p1.id", "http://jsvortex-regtest";);
user_pref("capability.principal.codebase.p1.subjectName", "");
...current caps implementation checks first if you have
signed.applets.codebase_principal_support enabled. If not enabled, caps
do not check if the user accepted or not the capabilities in the past.
This is at least what is currently implemented in
nsPrincipal::CanEnableCapability (I'm taking at look at
mozilla/caps/src/nsPrincipal.cpp).
Is this a bug or the expected behavior?
> > Ok, this solution seems to be more robust in the long term if I
> > understand you.
>
> Yeah, indeed.
Ok. I'm currently looking nsIObserver and examples around it.
> > Definitely exposing a particular and limited API looks like the right
> > thing. Is there any document or a working example implementing this
> > concept?
>
> Firebug does this with their console.* APIs, I believe...
Ok, I'll take a look on this. Cheers!
> -Boris
--
Francis Brosnan Blazquez <[email protected]>
ASPL
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
