The "initialization" steps for Web browsers
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.
continue; // early error; `tew` is not bound.
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>
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.
More information about the es-discuss