constants not visible in window




3 years ago
3 years ago


(Reporter: glazou, Unassigned)



Firefox Tracking Flags

(firefox48 affected)




3 years ago
While a |foo| variable is visible through a call to ||,
a |bar| const is always undefined through a call to ||.
This was not the case before the changes introduced for let and
const for ES6. Since I see nothing in ES6 that makes this mandatory
(this is more a conformance with Chrome), I'm filing this bug.


FWIW, a feature of BlueGriffon was completely horked because of that...
The standard does require this. Otherwise we would never have implemented it, as it horked a ton of stuff for us throughout Firefox. Ask :shu about it sometime.

I don't blame you for being unable to find this in the standard, which is practically impenetrable even for people who have lived in there for years. But here's the summary:

*   ECMA-262 15.1.11 GlobalDeclarationInstantiation
    <> specifies how global
    variable are set up; this happens just before the code of a script starts to run.
    Step 16.b.i.1 creates `const` bindings by calling CreateImmutableBinding.
    Step 18.a creates `var` bindings by calling CreateGlobalVarBinding.

*   CreateGlobalVarBinding is defined in
    <>. It creates a binding
    in envRec.[[ObjectRecord]] which entails defining a property on the global object.

*   CreateImmutableBinding for global environments is defined in
    It creates an entry in envRec.[[DeclarativeRecord]], which is the "global lexical scope".
    No objects are touched.

I don't like the global lexical scope. Never did. It's awful. But, we follow the spec.

Not sure if this will help, but there is also
which talks about all this nonsense in less technical terms.
Closed: 3 years ago
Resolution: --- → INVALID

Comment 2

3 years ago
Jason, thanks for the detailed info, and sorry then for the spam.
If I completely understand that following the spec is needed,
please allow me to say that part of the spec is stupid and impossible
to understand from a JS author's perspective who's not used to dive
into Ecma specs. I find this totally ridiculous and would definitely
and strongly support Mozilla if it brings the issue to Ecma (or bring
it again, more probably). Anyway, thanks again.
You need to log in before you can comment on or make changes to this bug.