There appears to be another case of spurious ReferenceErrors in if clauses, similar to bug 1274499, but for properties of the global object: In a JSM, add if (nonexistant) { ... } or if (!nonexistant) { ... } either at the global level or inside a function. This leads to "ReferenceError: nonexistant is not defined". if (this.nonexistant) and if (!this.nonexistant) work OK.

Bug 1274499 was caused by the introduction of new opcodes by Bug 1261826. In this case, this issue seems to be an issue from the fact that we might have different path for requesting non-existant names from the global than we do on objects. Note, this non-existant message is only a warning. Thus, the question would be if we are interested in emitting or not a warning if somebody made a typo. I honestly would think that the difference of behaviour might make sense, as testing a global can frequently be confused with a typo in a local variable name. (forwarding the ni? to Jason)

(In reply to Nicolas B. Pierron [:nbp] from comment #1) > Note, this non-existant message is only a warning. Thus, the question would > be if we are interested in emitting or not a warning if somebody made a typo. Imho the problem is that you'd be in effect adding another inconsistency to the way globals are treated.

Er, isn't |if (nameNotDefined) ...| *supposed* to throw a ReferenceError? Why isn't this standard, mandatory behavior?

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #3) > Er, isn't |if (nameNotDefined) ...| *supposed* to throw a ReferenceError? > Why isn't this standard, mandatory behavior? Hmm, I think that's right. It's only confusing when for some reason you're thinking of nameNotDefined as a property of the global object, and so expect undefined-property not undefined-variable behaviour.

The current behavior is required by the standard. Workarounds include `if (this.nonexistant)` and `if (typeof nonexistant !== "undefined")`.