311952 - eval(string) broken in XPInstall

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect, P2)

Description

[Karsten Düsterloh]

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.

Comment 1

[shutdown]

regression from bug 311025 and bug 311403.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 3

[Karsten Düsterloh]

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

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Run xpinstall on its own runtime

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 5

[Daniel Veditz [:dveditz]]

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

r=dveditz

Comment 6

[Brendan Eich [:brendan]]

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

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

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).

Comment 8

[Brendan Eich [:brendan]]

(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

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

Comment 10

[Karsten Düsterloh]

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

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Checked in on MOZILLA_1_8_BRANCH.

Comment 12

[Karsten Düsterloh]

Verified with Win32 Seamonkey trunk build 2005101205.