Having a line like this eval("666"); in your install.js makes XPInstall break with this (bogus?) error message in install.log: "function eval must be called directly, and not by way of a function of another name" in install.log" eval(666) just works fine. (This is very similar to bug 298054, just without the crash. :-/) I tracked down this trunk regression range: Win32 SeaMonkey trunk build 2005-10-06-06 is still okay, Win32 SeaMonkey trunk build 2005-10-07-06 is broken. If I set jsobj.c back to revision 3.214 to get rid of mrbkap's checkins there in the regression range, eval is working again.

regression from bug 311025 and bug 311403.

I've never dealt with xpinstall before. How exactly do I reproduce this (does it involve the xpi from bug 298054?)? eval(<non-string>) is exactly equivilant to |<non-string>|, which is why you don't see any bugs with it.

Yes, the XPI from attachment 186678 [details] in bug 298054 should suffice as a testcase.

For the record: the problem is that with the checkin to bug 311403, the JS engine says that if you provide a non-null findObjectPrincipals hook in the runtime, you must always provide non-null (not-ambiguous) principals to the engine or you'll be stopped. This patch makes xpinstall run on its own runtime.

Comment on attachment 199142 [details] [diff] [review] Run xpinstall on its own runtime r=dveditz

Comment on attachment 199142 [details] [diff] [review] Run xpinstall on its own runtime Use JS_NewRuntime, not the obsolete JS_Init synonym. Looks good otherwise. Pretty funny that this "wizard context?" fallback to a private runtime was always there. /be

Note to triagers: This bug does not yet exist on the branch, but is caused by bug 311403, which is a security fix that we will want to take on the branch. The patch is very simple -- to always create a new runtime instead of only creating one if a runtime cannot be found. dveditz informed me on IRC that xpinstall runs in its own little world (so it does not need to access the DOM and does not rely on the sharing of runtimes between its context and the global context).

(In reply to comment #7) > dveditz informed me on IRC that xpinstall runs > in its own little world (so it does not need to access the DOM and does not rely > on the sharing of runtimes between its context and the global context). On the last line, -e s/runtimes/objects/ -e s/context/runtime/g ;-) /be

Fix checked into trunk.

Yeah, works well in my local tree; will verify with a nightly asap. Thanks for the very quick fix!

Checked in on MOZILLA_1_8_BRANCH.

Verified with Win32 Seamonkey trunk build 2005101205.