The "initialization" steps for Web browsers

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


On 6/10/14, Ian Hickson <ian at hixie.ch> 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.

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

<script>
alert(rrq);
var rrq;
g; // ReferenceError, not an early error; `rrq` is bound.
</script>


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.
<script>
alert(gv); // contiguous context in same script.
var gv;
</script>
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io


More information about the es-discuss mailing list