MozillaWiki

Debugger: Difference between revisions

Page Discussion

Debugger (view source)

Revision as of 00:48, 11 January 2014

2,197 bytes added ,  11 January 2014
[master ed515ef] Rework source introduction metadata; add access for script's global.
([master fe5d673] Formatting tweaks for Debugger.Source merge.)
([master ed515ef] Rework source introduction metadata; add access for script's global.)
Line 553: Line 553:
<dt>sourceLength
<dt>sourceLength
<dd>The length, in characters, of this script's code within the <code>Debugger.Source</code> instance given by <code>source</code>.
<dd>The length, in characters, of this script's code within the <code>Debugger.Source</code> instance given by <code>source</code>.
<dt>global
<dd>A <code>Debugger.Object</code> instance referring to the global object in whose scope this script runs. The result refers to the global directly, not via a wrapper or a <code>WindowProxy</code> ("outer window", in Firefox).


<dt>staticLevel
<dt>staticLevel
Line 944: Line 947:
<dt>getVariable(<i>name</i>)
<dt>getVariable(<i>name</i>)
<dd>Return the value of the variable bound to <i>name</i> in this environment, or <code>undefined</code> if this environment does not bind <i>name</i>. <i>Name</i> must be a string that is a valid ECMAScript identifier name. The result is a debuggee value.
<dd>Return the value of the variable bound to <i>name</i> in this environment, or <code>undefined</code> if this environment does not bind <i>name</i>. <i>Name</i> must be a string that is a valid ECMAScript identifier name. The result is a debuggee value.
JavaScript engines often omit variables from environments, to save space and reduce execution time. If the given variable should be in scope, but <code>getVariable</code> is unable to produce its value, it returns an ordinary JavaScript object (not a <code>Debugger.Object</code> instance) whose <code>optimizedOut</code> property is <code>true</code>.


This is not an [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function]]; if this call would cause debuggee code to run (say, because the environment is a <code>"with"</code> environment, and <i>name</i> refers to an accessor property of the <code>with</code> statement's operand), this call throws a [[#The_Debugger.DebuggeeWouldRun_Exception|<code>Debugger.DebuggeeWouldRun</code>]] exception.
This is not an [[#Invocation_Functions_and_.22debugger.22_Frames|invocation function]]; if this call would cause debuggee code to run (say, because the environment is a <code>"with"</code> environment, and <i>name</i> refers to an accessor property of the <code>with</code> statement's operand), this call throws a [[#The_Debugger.DebuggeeWouldRun_Exception|<code>Debugger.DebuggeeWouldRun</code>]] exception.
Line 1,042: Line 1,047:
<dd>If this source belongs to a DOM element because it is an event handler content attribute or an event handler IDL attribute, this is the name of that attribute, a string. Otherwise, this is <code>undefined</code>.
<dd>If this source belongs to a DOM element because it is an event handler content attribute or an event handler IDL attribute, this is the name of that attribute, a string. Otherwise, this is <code>undefined</code>.


<dt>introductionScript <i>(not yet implemented)</i>
<dt>introductionType <i>(not yet implemented)</i>
<dd>If this source was passed to an <i>introduction call</i> in debuggee code, this is the <code>Debugger.Script</code> instance referring to the script containing that call. Otherwise, this is <code>undefined</code>. (Taken together with the <code>introductionScriptOffset</code> property, one can determine the call's source and position within that source of the call.)
<dd>A string indicating how this source code was introduced into the system. This accessor returns one of the following values:
 
An introduction call is a function call (or assignment to a setter property) that introduces new JavaScript code to the system. This is one of the following:
<ul>
<ul>
<li>A call to <code>eval</code>.
<li><code>"eval"</code>, for code passed to <code>eval</code>.
<li>A call to the <code>Function</code> constructor.
<li><code>"Function"</code>, for code passed to the <code>Function</code> constructor.
<li>A call to the <code>Worker</code> web worker constructor or the <code>importScripts</code> function, which expect a script URL.
<li><code>"Worker"</code>, for code loaded by calling the Web worker constructor&mdash;the worker's main script.
<li>An assignment to an event handler IDL attribute of a DOM element.
<li><code>"importScripts"</code>, for code by calling <code>importScripts</code> in a web worker.
<li><code>"handler"</code>, for code assigned to DOM elements' event handler IDL attributes.
<li><code>"scriptElement"</code>, for code belonging to <code>&lt;script&gt;</code> elements.
<li><code>undefined</code>, if the implementation doesn't know how the code was introduced.
</ul>
</ul>


<dt>introductionScript <i>(not yet implemented)</i>
<dt>introductionScriptOffset <i>(not yet implemented)</i>
<dt>introductionScriptOffset <i>(not yet implemented)</i>
<dd>If <code>introductionScript</code> is a script, this is the bytecode offset within that script of the introduction call.
<dd>If this source was introduced by calling a function from debuggee code, then <code>introductionScript</code> is the <code>Debugger.Script</code> instance referring to the script containing that call, and <code>introductionScriptOffset</code> is the call's bytecode offset within that script. Otherwise, these are both <code>undefined</code>. Taken together, these properties indicate the location of the introducing call.


<dt>introductionKind <i>(not yet implemented)</i>
For the purposes of these accessors, assignments to accessor properties are treated as function calls. Thus, setting a DOM element's event handler IDL attribute by assigning to the corresponding JavaScript property creates a source whose <code>introductionScript</code> and <code>introductionScriptOffset</code> refer to the property assignment.
<dd>A string indicating what kind of introduction call introduced this <code>Debugger.Source</code>'s code into the system. This is <code>undefined</code> if <code>introductionScript</code> is undefined; otherwise, it is one of the following strings:
 
<ul>
Since a <code>&lt;script&gt;</code> element parsed from a web page's original HTML was not introduced by any scripted call, its source's <code>introductionScript</code> and <code>introductionScriptOffset</code> accessors both return <code>undefined</code>.
<li><code>"eval"</code>
 
<li><code>"Function"</code>
If a <code>&lt;script&gt;</code> element was dynamically inserted into a document, then these accessors refer to the call that actually caused the script to run&mdash;usually the call that made the element part of the document. Thus, they do <i>not</i> refer to the call that created the element; stored the source as the element's text child; made the element a child of some uninserted parent node that was later inserted; or the like.
<li><code>"Worker"</code>
<li><code>"importScripts"</code>
<li><code>"handler"</code> (for DOM elements' event handler IDL attributes)
</ul>


Although the main script of a worker thread is introduced by a call to <code>Worker</code> or <code>SharedWorker</code>, these accessors always return <code>undefined</code> on such script's sources. A worker's main script source and the call that created the worker are always in separate threads, but <code>Debugger</code> is an inherently single-threaded facility: its debuggees must all run in the same thread. Since the global that created the worker is in a different thread, it is guaranteed not to be a debuggee of the <code>Debugger</code> instance that owns this source; and thus the creating call is never "in debuggee code". Relating a worker to its creator, and other multi-threaded debugging concerns, are out of scope for <code>Debugger</code>.
</dl>
</dl>


Jimb
Confirmed users
497

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/880072"