decrement console._stopLevel in cont() and step() functions, like good little boys and girls
initDebugger *after* setting up the console routines, we'll need them
set up the excetions submenu checkmarks correctly onCreate
load the source if it's not there in onDebugTrap
add onDebugContinue to clear our state when we continue
implement tmode command
move onclose back to onunload, onclose doesn't fire if the user selects "Quit" from the file menu.
add tmode command to trace/ break when the target throws an exception.
fix "breakpoint hit while servicing breakpoint" behavior. When we hit the second breakpoint, its stack is put on top of the current stack. Not the best solution, but better than leaving the user in an undefined state.
distunguish between executable and non-executable lines in the source array so we can distinguish the lines in CSS.
expand tabs in the source (outliner doesn't know what to do with \t.)
if we can't load a source file sync, try it async.
move debug object counters and various constructors to jsd_xpc.cpp
add LiveEphemeral struct to reperesent a link in a PRCList of ephemeral objects.
declare jsdIEphemeral interface in objects that need it, add invalidaAll static method to jsdIProperty and jsdIValue. jsdIObject still needs work.
Large changes to improve the way we deal with our wrappers around js engine structures. jsdIScript, jsdIStackFrame, jsdIValue, and jsdIProperty interfaces now inherit from a new interface "jsdIEphemeral". This interface is used to invalidate the wrapper. Once the wrapper is invalidated, *most* methods throw NS_ERROR_NOT_AVAILABLE, some interfaces, such as jsdIScript, cache important information so that the wrapper isn't utterly useless once it has been invalidated. The boolean isValid attribute can be used to see if the wrapper is still valid.
factor debug object counters into some simple macros
add new velid assertion macros for the new ephemeral objects
add utility functions for dealing with PR_CLISTs full of ephemeral objects.
invalidate the jsdIFrame after the execution hook completes
move some c/dtors from jsd_xpc.h over here to avoid exposing debug object counters, and repeating some macros
fix incorrectly set out parameter in getValue::GetDoubleValue
Subject:
Re: Rhino: [[DefaultValue]] missing for Call object
Resent-Date:
Mon, 2 Jul 2001 08:52:07 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
Mon, 02 Jul 2001 11:49:59 -0400
From:
Norris Boyd <nboyd@atg.com>
Organization:
Art Technology Group
To:
Christopher Oliver <coliver@mminternet.com>
CC:
mozilla-jseng@mozilla.org
References:
1
I believe the correct result of the script should be
[object global]
[object Object]
[object global]
The activation object (which goes by the name of "Call" for historical
reasons) should never be the 'this' value in a function call. See "10.1.6
Activation Object" in the ECMA spec.
I'll look at fixing the problem for Rhino. If there's agreement on my
analysis, someone should fix this for Spidermonkey too.
--N
Christopher Oliver wrote:
> Hi,
>
> function a() {
> function b() {
> print(this);
> }
> this.f = function() {
> print(this);
> b();
> }
> b();
> }
>
> var a = new a();
> a.f();
>
> Running the above script with SpiderMonkey produces:
>
> [object global]
> [object Object]
> [object Call]
>
> Running with Rhino produces the following exception:
>
> uncaught JavaScript exception: undefined: Cannot find default value for
> object. (line 3)
>
> This is due to a bug in org.mozilla.javascript.NativeCall which doesn't
> implement toString or valueOf or override getDefaultValue.
> However, even after I hacked in an implementation of getDefaultValue in
> NativeCall, Rhino still produces a different result then spidermonkey:
>
> [object Call]
> [object Object]
> [object Call]
rginda%netscape.com
cotter%netscape.com
nicolson%netscape.com
wtc%netscape.com
alecf%netscape.com
mkaply%us.ibm.com
bstell%netscape.com
cls%seawood.org
jaggernaut%netscape.com
dianesun%netscape.com
racham%netscape.com
hewitt%netscape.com
ben%netscape.com
mstoltz%netscape.com
sspitzer%netscape.com
timeless%mac.com
oeschger%netscape.com
dbaron%fas.harvard.edu
nboyd%atg.com