The default bug view has changed. See this FAQ.

eval(string) broken in XPInstall

VERIFIED FIXED in mozilla1.8rc1

Status

Core Graveyard
Installer: XPInstall Engine
P2
major
VERIFIED FIXED
12 years ago
a year ago

People

(Reporter: Karsten Düsterloh, Assigned: mrbkap)

Tracking

({fixed1.8, regression})

Trunk
mozilla1.8rc1
x86
Windows 2000
fixed1.8, regression
Bug Flags:
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

12 years ago
regression from bug 311025 and bug 311403.
(Assignee)

Comment 2

12 years ago
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

Updated

12 years ago
Flags: blocking1.8rc1?
(Reporter)

Comment 3

12 years ago
Yes, the XPI from attachment 186678 [details] in bug 298054 should suffice as a testcase.
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

12 years ago
Created attachment 199142 [details] [diff] [review]
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.
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+
(Assignee)

Updated

12 years ago
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?
(Assignee)

Comment 7

12 years ago
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).
(Assignee)

Updated

12 years ago
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
(Assignee)

Comment 9

12 years ago
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Attachment #199142 - Flags: approval1.8rc1? → approval1.8rc1+
(Reporter)

Comment 10

12 years ago
Yeah, works well in my local tree; will verify with a nightly asap.
Thanks for the very quick fix!
(Assignee)

Comment 11

12 years ago
Checked in on MOZILLA_1_8_BRANCH.
Keywords: fixed1.8

Updated

12 years ago
Flags: blocking1.8rc1? → blocking1.8rc1+
(Reporter)

Comment 12

12 years ago
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.