Closed Bug 17736 Opened 21 years ago Closed 20 years ago

DOM objects crash on non DOM JSContext


(Core :: DOM: Core & HTML, defect, P3)






(Reporter: jband_mozilla, Assigned: jband_mozilla)




(1 file)

As discussed in email... The DOM objects created by idlc and some of those
handwritten assume that the JS_ContextPrivate will always cough up a
nsJSContext. This will not be true when bug 13419 is fixed (which is ready to

Brendan suggested a system whereby we walk up the object parent tree to the
global object, checking that object's class to verify that it has a private of
then QI'ing that private to nsIScriptGlobalObject (right?).

We will also what to offload some stuff from nsJSContext into that global object
interface. e.g. the security manager and namespace manager references and all
that entails.

I checked in my changes for bug 13419. They are disabled using a comment until
this is fixed. They can be used for testing. in xpcwrappedjsclass.cpp do the
following in the two places where 'AutoPushCompatibleJSContext' appears...

< //    AutoPushCompatibleJSContext autoContext(GetJSContext());
< //    JSContext* cx = autoContext.GetJSContext();
<     JSContext* cx = GetJSContext();
>     AutoPushCompatibleJSContext autoContext(GetJSContext());
>     JSContext* cx = autoContext.GetJSContext();
> //    JSContext* cx = GetJSContext();

With this change you should see crashing in (at least) the mail compose window
on document end load.

I have some changes to the xpconnect test components that uses a wrapped JS
object call to nsITimer to trigger this bug in a simpler case. I'll get this in
soon and then attach the html to use the component to this bug.

So who is up for doing the work? I'm busy doing an xpconnect refactoring to fix
its version of this 'JSContext is the locus object' problem. I can do this too
if no one else is going to do it. Brendan has had his nose in this code
and claimed that he might do this work if no one else volunteers. vidur, please
reassign if you'd rather not attack this yourself.
Blocks: 17952
No longer blocks: 17952
I attached the test html that will trigger the calling of a JS function on a non
-DOM context (after that changes to xpcwrappedjsclass.cpp noted above).

This code uses a method on the nsIEcho test object implementation in the
xpctest components which is unfortunately only implemented for Win32 - the
nsITimer stuff is in a static lib built in widgetland and caused build order
problems when I tried to link it into the DLL made in xpconnect/tests/components
on a clobber build on Unix. For NT it works fine.
Assignee: vidur → jband
Spoke to jband about this at great length. Our options include:
1) Creating a service for JSContext creation. All JSContexts created by the
service would match the assumptions made by the DOM.
2) Have the DOM prime the thread-local context stack and make sure everyone uses
3) Do the right thing and remove all calls to JS_ContextPrivate and take some of
the other steps suggested by jband.

Since the last step will involve a substantial change to both generated and
hand-written code, jband and I decided to defer it for a bit. Reassigning to
jband to hold the bug until we get around to dealing with it. He might consider
one of the other options in the interim.
I'm branching JS, XUL and DOM for the rest of brutal sharing.  I'll take a stab
at moving stuff out of context and into window private, if it's ok with y'all.

Blocks: 17952, 18702
Hope these deps are true -- yell if not.

No longer blocks: 18702
removed the dependency for 18702. I fixed this.
Blocks: 21564
Closed: 20 years ago
Resolution: --- → FIXED
Today's checkins to DOM and xpconnect code fix this. My attached timer test
now works.
Verified according to Jbands comments.
No longer blocks: 21564
You need to log in before you can comment on or make changes to this bug.