Backed out changeset d988238c67d8; bug number was wrong in comment. DONTBUILD
authorJim Blandy <jimb@mozilla.com>
Thu, 10 Jul 2014 17:32:42 -0700
changeset 214309 c82f6909c26c6b13a02af0522a9bca2b89bbcf60
parent 214308 d988238c67d80db0e1f770399523b313a0eacef9
child 214310 83e4d5c39c66b289fc10ec803615bdb063e0b39a
push id3857
push userraliiev@mozilla.com
push dateTue, 02 Sep 2014 16:39:23 +0000
treeherdermozilla-beta@5638b907b505 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
milestone33.0a1
backs outd988238c67d80db0e1f770399523b313a0eacef9
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Backed out changeset d988238c67d8; bug number was wrong in comment. DONTBUILD
js/src/doc/Debugger/Debugger.Source.md
--- a/js/src/doc/Debugger/Debugger.Source.md
+++ b/js/src/doc/Debugger/Debugger.Source.md
@@ -126,52 +126,52 @@ from its prototype:
 
     * `"setTimeout"`, for code passed to `setTimeout` as a string.
 
     * `"setInterval"`, for code passed to `setInterval` as a string.
 
     * `undefined`, if the implementation doesn't know how the code was
       introduced.
 
-`introductionScript`, `introductionOffset`
-:   If this source was introduced by calling a function from debuggee code, then
-    `introductionScript` is the [`Debugger.Script`][script] instance referring
-    to the script containing that call, and `introductionOffset` is the call's
-    bytecode offset within that script. Otherwise, these are both `undefined`.
-    Taken together, these properties indicate the location of the introducing
-    call.
+`introductionScript`, `introductionScriptOffset` <i>(future plan)</i>
+:   If this source was introduced by calling a function from debuggee code,
+    then `introductionScript` is the [`Debugger.Script`][script] instance referring to
+    the script containing that call, and `introductionScriptOffset` is the
+    call's bytecode offset within that script. Otherwise, these are both
+    `undefined`. Taken together, these properties indicate the location of
+    the introducing call.
 
-    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 `introductionScript` and `introductionOffset` refer to the
-    property assignment.
+    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 `introductionScript` and
+    `introductionScriptOffset` refer to the property assignment.
 
-    Since a `<script>` element parsed from a web page's original HTML was not
-    introduced by any scripted call, its source's `introductionScript` and
-    `introductionOffset` accessors both return `undefined`.
+    Since a `<script>` element parsed from a web page's original HTML
+    was not introduced by any scripted call, its source's
+    `introductionScript` and `introductionScriptOffset` accessors both
+    return `undefined`.
 
-    If a `<script>` element was dynamically inserted into a document, then these
-    accessors refer to the call that actually caused the script to run—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.
+    If a `<script>` element was dynamically inserted into a document,
+    then these accessors refer to the call that actually caused the script
+    to run—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.
 
     Although the main script of a worker thread is introduced by a call to
     `Worker` or `SharedWorker`, these accessors always return `undefined` on
     such script's sources. A worker's main script source and the call that
-    created the worker are always in separate threads, but
-    [`Debugger`][debugger-object] 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 [`Debugger`][debugger-object] 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
-    [`Debugger`][debugger-object].
+    created the worker are always in separate threads, but [`Debugger`][debugger-object] 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 [`Debugger`][debugger-object] 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 [`Debugger`][debugger-object].
 
 
 
 ## Function Properties of the Debugger.Source Prototype Object
 
 <code>substring(<i>start</i>, [<i>end</i>])</code> <i>(future plan)</i>
 :   Return a substring of this instance's `source` property, starting at
     <i>start</i> and extending to, but not including, <i>end</i>. If