The "initialization" steps for Web browsers

Garrett Smith dhtmlkitchen at
Tue Jun 10 14:31:06 PDT 2014

On 6/10/14, Ian Hickson <ian at> wrote:
> On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:

Hi Ian; Allen.

> > (Also, how could step 6's substeps ever get triggered?)
>> Working backwards, step 5 does many things, some of which are specified
>> as having error conditions and exceptions, so I have to take into
>> account what happens if any errors occur. Step 6, just says that if they
>> do then the startup of the ES environment has failed.  If an implementor
>> can prove that they [can't] trigger any of those error conditions then
>> they don't have to worry about it.  But for completeness, I do.
> Do you have an example of how any of those steps could fail?

I'm guessing that applies for any early error.

var tew;
continue; // early error; `tew` is not bound.

var rrq;
g; // ReferenceError, not an early error; `rrq` is bound.

The following example results in a ReferenceError. Although `gv` is
defined, that does not occur until the subsequent <script>. After the
browser has reached the first </script>, the Program is evaluated, and
at that point, the global Lexical Environment Record does not have a
`gv` property. Where and how is this behavior described?
<script>alert(gv); // context to subsequent script is segmented. </script>
<script>var gv;</script>

I vaguely remember seeing examples more complex than the example
above, including dealings with the global scope polluter, and with
more divergent behavior.

Moving `gv` to the same script results results in no such runtime
error, as is explained in ES3.
alert(gv); // contiguous context in same script.
var gv;

More information about the es-discuss mailing list