Closed Bug 55506 Opened 25 years ago Closed 25 years ago

Access denied on invokation of a XPconnect service from JavaScript.

Categories

(Core :: XPConnect, defect, P3)

Product:
Core
Component:
XPConnect
Platform:
Sun
Solaris
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rpallath, Assigned: jband_mozilla)

References

Details

(Whiteboard: [rtm-])

Attachments

(3 files)

proposed fix (patch w/ CRLF line endings)
2.31 KB, patch
Details | Diff | Splinter Review
proposed fix round 2
4.02 KB, patch
Details | Diff | Splinter Review
proposed fix round 3 (make it always OK to fail)
4.07 KB, patch
Details | Diff | Splinter Review
Not sure if this is the right component to file this bug under. I stumbled on a weird problem while running thru' my OJI (Open JVM integration) tests. If It is my first invokation of mozilla (no component.reg) and I try to load the page (test.html shown below), as ./run-mozilla.sh ./mozilla-bin file://test.html it throws JavaScript error: line 0: uncaught exception: Access to XPConnect service denied. However if I run it the second time it brings up a popup box prompting user to allow the acces or not (Ok/Cancel buttons prived with 'Remember decision' option). It should have prompted that box even the first time. but it does not That is the bug. Below is listing of test.html. test.html ---------- <html> <head> <script> netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect"); var OJITestLoader = Components.classes['@mozilla.org/oji/test/api/loader;1'].createInstance(); } </script> </head> <body> It invokes a XPCcoonect callf or JavaScript </body>
I've run into this myself. The problem is that the JS Component Loader uses the security manager very early in startup when JS component registration is required. This makes the security manager start up before the component *it* uses to register the 'nameset' for 'netscape.security' has been (dynamically) registered. So... In this case all attempts to access netscape.security just fail for the rest of the application run. This will affect other things too on first browser run. I have a fix to defer the nameset registration until nsScriptSecurityManager::CanExecuteScripts. It happens each time that method is called until it succeeds and then does not happen again. I'll attach the patch. it works for me. mstoltz, do you approve of this change to your caps module? reviews?
Status: NEW → ASSIGNED
Keywords: patch
I'd like it if the AddExternalNameSet also got called when nsScriptSecurityManager starts up, on the off chave that someone tries to use the caps API before CanExecuteScriptsis ever called. This may never happen, but I don't want to introduce a hidden dependency that CanExecuteScripts must be called before any use of the caps API. That will come back to haunt us. Other than that, the patch looks OK. John will post a new patch.
[please ignore fix "round 2". "round 3" is better I think] I attached a patch that will try to register the nameset at the same time as the old code did and also try again later if that failed. This one does not make it an error to fail in the registration - even from within CanExecuteScripts. r= a= ???
Looks good to me: r=shaver
ditto. r=mstoltz
Actually, make that a=mstoltz as module owner.
Who spread this idea that module owners give a=? It's not anything I recall in the long history of a= (which goes back to M12, IIRC). a=brendan@mozilla.org, adding rtm keyword. /be
Keywords: rtm
my bad.
Depends on: 55460
*** Bug 35116 has been marked as a duplicate of this bug. ***
As per discussion with jband, marking status as rtm-, because this is a first-run-only problem.
Whiteboard: [rtm-]
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: