Closed Bug 311952 Opened 16 years ago Closed 16 years ago

eval(string) broken in XPInstall

Categories

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

x86
Windows 2000

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.8rc1

People

(Reporter: mnyromyr, Assigned: mrbkap)

References

Details

(Keywords: fixed1.8, regression)

Attachments

(1 file)

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.
Priority: -- → P2
Target Milestone: --- → mozilla1.8rc1
Flags: blocking1.8rc1?
Yes, the XPI from attachment 186678 [details] in bug 298054 should suffice as a testcase.
Status: NEW → ASSIGNED
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.
Attachment #199142 - Flags: review?(dveditz)
Comment on attachment 199142 [details] [diff] [review]
Run xpinstall on its own runtime

r=dveditz
Attachment #199142 - Flags: review?(dveditz) → review+
Attachment #199142 - Flags: superreview?(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
Attachment #199142 - Flags: superreview?(brendan)
Attachment #199142 - Flags: superreview+
Attachment #199142 - Flags: approval1.8rc1?
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).
Blocks: 311403
(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.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attachment #199142 - Flags: approval1.8rc1? → approval1.8rc1+
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.
Keywords: fixed1.8
Flags: blocking1.8rc1? → blocking1.8rc1+
Verified with Win32 Seamonkey trunk build 2005101205.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.