Closed Bug 35116 Opened 24 years ago Closed 24 years ago

netscape global unavailable after new component registration

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 55506

People

(Reporter: thayes0993, Assigned: shaver)

Details

After installing a new JS XPCOM component (usually updating a previous one),
attempts to access netscape.security.PrivilegeManager fail.  The error generated
is "ReferenceError: netscape is not defined"

To reproduce, create a simple JS XPCOM component (just copy the sample) and
install it.  Then after starting Mozilla, attempt to call a PrivilegeManager
function (see http://jazz.mcom.com/users/thayes/publish/Xul/simple1.html" for a
script that does this)
Shaver do you own js component loader. This could have to do something with it 
or JS. Ccing jband. Assigning to shaver.
Assignee: dp → shaver
It looks like this code should call InitializeClasses on the  
nsIScriptNameSetRegistry service.

See 
http://lxr.mozilla.org/seamonkey/search?string=nsJSContext%3A%3AInitializeExt

I wonder if the caps stuff is going to blowup in some interesting way if this is 
done on a non-DOM JSContext.

Should it be initializing liveconnect too? (see the method in nsJSContext just 
below the above).

xpcPerThreadData::GetSafeJSContext() probably ought to do the same.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Shoot! This uses nsIScriptExternalNameSet which talks about nsIScriptContexts 
instead of JSContexts. Hackery will be required.
mccabe, do you know what the state of said hackery is?

Are you trying to call the PrivilegeManager from component JS?  That would seem
unnecessary, since component JS already has chrome-level priveleges.

The initial report is for JS in XUL or HTML files (not chrome).  I use this to 
test new XPCOM components.  After changing (and re-registering the component) 
the netscape globa is not defined.  Restarting (no registration this time) 
allows the test JS to work.
I've seen this problem as well. The first time I run Seamonkey after building, I 
get this error. Subsequent runs work fine.

I'll take a swing at this today.  Will people out there be ready to test a
patch?
Status: NEW → ASSIGNED
Target Milestone: --- → M16
OK, I guess I'm not understanding how this happens.  How can the JS component
loader be affecting the scope objects in the DOM?

I don't understand jband's comment, either, but he's not here to explain it.  If
``this code'' refers to the JS component loader, I don't think it'll help: the
code in question is in the DOM-JS world, so making netscape.* and liveconnect
available to JS components, while cool, is unlikely to help.

mccabe, did jband share any of this with you?

I can test on Unix.

M16 has been out for a while now, these bugs target milestones need to be 
updated.
I'm sorry I muddied the waters with my comments. I completely misunderstood the 
bug report. I though that the problem was that one can not call 
'netscape.security...." from a JS component. A digression here... I realize now 
that we are giving the JS component all the power they need. However, I do think 
that it would be good to implement a do-nothing set of netscape.security.* 
methods on the JS loader's global object so that people can use libraries of 
code in both html and JS components and can call those security methods safely 
without regard to which envirnoment the code snipet happens to be running.

That aside... Once I reread this and realized what Terry was saying, It occured 
to me that the fact that the JS loader is running early on to register a 'new' 
component must be having a long lasting bad side effect. My first thought was 
that the loader might be leaving a a JSContext on the context stack. Since the 
DOM code likes to suck the global object out of the JSContext for use I thought 
this might be the problem.

As it happens the JS loader *does* have some exceptional code paths in the two 
places where it pushes and pops JSContexts that return immediately rather than 
doing a goto to the cleanup (and pop) code. This ought to be fixed.

But this was not the problem.

The lookup for 'additional' toplevel names is done using a service that 
implements nsIScriptNameSetRegistry. When the ScriptSecurityManager first starts 
up it tries to register itself with that service so that it will later be called  
to initialize that top level name each time the DOM inits a window.
http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#143
3

However, this nsIScriptNameSetRegistry is one of the dumb services that is 
inited ever time the app starts (in SetupRegistry) rather than being 
persistently registered in the component registry.
http://lxr.mozilla.org/seamonkey/source/webshell/tests/viewer/nsSetupRegistry.cp
p#183

And, now that the JSLoader is using the ScriptSecurityManager to get principals 
we have a case where the ScriptSecurityManager is getting its one and only init 
call *before* the nsIScriptNameSetRegistry service is registered.

http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/loader/mozJSComponentLo
ader.cpp#911

The loader autoreg happens before the SetupRegistry stuff. So, when there are 
new JS components (or maybe if we implement a JS components that happens to get 
used early in the app startup?) the ScriptSecurityManager silently fails to do 
its dance with the nsIScriptNameSetRegistry service and so *no* global objects 
later created get there netscape.security.* methods because the 
ScriptSecurityManager missed its chance to get added to the list.

And by the way, with Java not installed, I see a crash as LiveConnect tries to 
do a name lookup for one or the other parts of "netscape.security". I'll file a 
separate bug on that.

So, what to do? Fix when the nsIScriptNameSetRegistry service gets registered? 
Make the ScriptSecurityManager keep trying to do its dance with that service on 
subsequent calls until it actually succeeds? Something else?
I think this was fixed by some of jband's recent work, in which he made it so
that we keep trying to register names until it works, but my bugzilla
archaeology can't find the bug in question.  jband, can you confirm or deny?

marking this as a dup because I have a patch for this in the other bug.

*** This bug has been marked as a duplicate of 55506 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
vrfy dupe of fixed bug 55506
Status: RESOLVED → VERIFIED
Component: XPCOM Registry → XPCOM
QA Contact: leger → xpcom
You need to log in before you can comment on or make changes to this bug.