global breaks flickr.com

[evilpie]

See bug 1325907 . Just the existence of global seems to break flickr.com. This caused by code in the popular moment/moment library.

[ljharb]

The referenced code - https:/moment/moment/blob/94ad539f965689289af54b6493abca0a65ab4ce6/moment.js#L15 - should work identically with global, unless the file is naively concatenated such that it's in strict mode, such that top-level this isn't the global object.

Is that what Flickr is doing? If so, lots of things might be broken by their build process :-/

[ziyunfei]

The moment.js code is wrapped in a YUI module:

YUI.add("moment", function(e, t) {
  alert(this === global) // false 
}, "@VERSION@")

[ljharb]

In that case, moment should not be wrapping YUI, since that would break in node.

I realize this doesn't change the web compatibility issue - but it does highlight the incorrect assumptions that were made when wrapping moment.

@evilpie are there any other reports? I feel like we should be able to evangelize to Yahoo and get them to update Flickr, and similarly, update moment via a PR, which would remove the web compat breakage.

[ziyunfei]

The typeof global checking had already been removed from new versions of moment.js.

[ljharb]

Given that, it sounds like we just need to get Flickr/Yahoo to update the version of moment that it's using, and the problem goes away. @evilpie, if this happens, would we be able to try this again in Firefox?

[jswalden]

Unless I'm misreading the code (entirely possible), #20 (comment) looks wrong to me. Flickr's moment.js code is identical to that on trunk, and that's been on trunk since moment/moment@1601cb1 two years ago. The seeming difference between

(typeof global !== 'undefined' && (typeof window === 'undefined' || window === global.window)) ? global : this

and

typeof global == "undefined" || typeof window != "undefined" && window !== global.window ? this : global

is purely the result of minifying: applying de Morgan's Laws, removing parentheses that aren't necessary by language precedence order, and trimming strict-equality operators to loose equality when both operands always have the same type.

The issue here is purely that Flickr is embedding moment.js code, that uses this presuming it's the global object, in a context where this is not the global object.

[ljharb]

@jswalden thanks, I think your conclusion is correct.

[ljharb]

Another example has popped up in Firefox: bug 1326032

[littledan]

This is all very sad. Sounds like we can't go with the name global for a long time. I'd be very hesitant to put this in V8 given the evidence already collected from Firefox.

[miketaylr]

Another example has popped up in Firefox: bug 1326032

Also, JIRA, in https://bugzilla.mozilla.org/show_bug.cgi?id=1328218 (due to moment.js).

[evilpie]

I should mention we removed global from Nightly again.

[nt1m]

@evilpie : I agree with https://bugzilla.mozilla.org/show_bug.cgi?id=1317422#c18
Can't we have it for strict contexts? That would limit the amount of pages affected if any

[evilpie]

I don't think so. Consider two scripts included in HTML, they can have different strictness, but they still have the same global object, with the "global" on it.

[ljharb]

We might be able to add it in Modules, but adding it in strict mode wouldn't work - you may forget that a Script can have function sloppy() {} function strict() { 'use strict'; } - global isn't a keyword, so it can't have contextual meaning, and it'd be really weird for a string pragma to bring something into scope.

[rjgotten]

@jswalden
Unless I'm misreading the code (entirely possible)

You are misreading the code. Those lines are not at all there in trunk, i.e., in https:/moment/moment/blob/master/moment.js

They're there in version 2.0.9 which was tagged 2015-01-02, but were removed when version 2.10.2 which was tagged 2015-04-09, introduced a UMD wrapper.

So yes; this would be resolved by Yahoo/Flickr/etc. updating their codebase.

[littledan]

@ljharb Modules have the same global object as non-modules. You'd add this in the global lexical tier? That would be a new one. Is there anything else we might want to add this way? Adding it only in modules would give this feature significantly diminished utility as well.

What if we named this 'self'? Have we seen evidence that that would break the Node world?

[targos]

What if we named this 'self'? Have we seen evidence that that would break the Node world?

I can try to add self to Node and see if CITGM breaks.

Edit:
CITGM run: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/520/

[ljharb]

I won't be actually pursuing "add it only in Modules", I agree the utility would be greatly reduced.

The proper solution here is either to come up with a web-compatible top-level name that has "global" in it ("self" is a terrible name), or to namespace it under a new or existing web-compatible top-level name.

[michaelficarra]

It looks like we have reason to introduce System.global after all.

[leobalter]

If we want to avoid a namespace my suggestion is to pursue something not perfect but less likely to break web compat as __global__, or even $$global. It hurts my eyes, but it's still a single name binding with a safer approach avoiding namespace.

[jakub-g]

__global__ seems rather safe IMO, and in line with stuff like__proto__. Though indeed it looks ugly.

[ljharb]

@targos it looked like the CIGTM run failed a bunch of the jobs?

[ljharb]

@leobalter System.global is far more elegant than __global__ or $$global, though, and a namespace of any kind allows for us to use "global" untainted by legacy characters.

[kdzwinel]

FYI Safari Technology Preview 21 was just released and it features support for the global property. flickr.com doesn't work, but JIRA (v6.2) seems to be working fine for me.

[ljharb]

@kdzwinel can you comment on the firefox bug related to jira? It should be broken in both places if this is indeed the cause.

[miketaylr]

FYI Safari Technology Preview 21 was just released and it features support for the global property. flickr.com doesn't work, but JIRA (v6.2) seems to be working fine for me.

And backed out: https://bugs.webkit.org/show_bug.cgi?id=166915

[ljharb]

(Turns out it requires a newer Jira version to get the failure)

[ljharb]

@sag1v there’s precedent for __global__ but the aesthetics of that aren’t what I’d call “likely to satisfy the committee”, nor myself.

[svdb0]

A few more ideas, which have their own pros and cons:

• that (contrast with this)
• __ (double underscore)
• [Symbol.global] on any object
• Object.global (always accessible as ({}).constructor.global)
• const.global, var.global, default.global, or true.global (meta-property similar to new.target)
• default (no ambiguity with the keyword, I think, though it might be confusing)

[ljharb]

@svdb0 at this point, it needs to be a global variable - it can't be something applicable to any object - double underscores aren't what i'd call "aesthetically pleasing" - a metaproperty or keyword wouldn't be replaceable by secure realm tools like caja, so it has to be an identifier.

[Licshee]

To me, self sounds like a reasonable name for global object in "JavaScript", since it is already standardized in HTML:
https://developer.mozilla.org/en-US/docs/Web/API/Window/self
https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/self

And people already using self outside of HTML:
https:/sergeche/emmet-sublime/blob/master/emmet/bootstrap.js

The biggest problem so far is -- there are many people still using window even if the code is not necessary running on HTML, and it should be no more if either self or global made into standard.

So I believe the only thing we need to do is making self into the standard.

FAQ

Isn't self a terrible name?

Yes, but web developers already getting used with it, seconded to window, which is a worse choice for general-purposed ECMAScript.
And since the standardized self in HTML means basically the same thing, it should not be a problem implementing into browsers.

Does it conflict with other use?

I don't think so.
Historical, people tend to use self or that to "snapshot" this in current scope, the point is at any moment the code introduce a new var self, it has nothing to do with other selfs outside current scope, and that's why people use self or that or something else to replace this when they need to pass the current this into a nested function implementation.
If we make it a standard global self point to the global object itself, it should not cause problem, since there should be no code expects a global self exists or not, even if in some cases developer(s) already getting used with self being the global object itself.

Why not global?

https://nodejs.org/api/globals.html#globals_global
In Node.js, global is a completely different animal, it will cause compatibility problems -- or at least Node.js users still have to use something like self.
I can't believe that you still tried to put global into the standard even since Node.js already used it for other purpose.
Also, as people mentioned above, some website(s) already used global for other purpose(s).

Wait... Doesn't it mean if we made self into standard, all existing code involving self or global object have to be rewritten?

No.

1. If existing code use variables like global or something, a standardized self has nothing to do with them, and don't require changes to the code.
2. If any existing code already use self for any purpose, the standardized self should simply be overwritten, and cause no problem.
3. If existing code used self for purpose other than an alias for global object and willing to use global object in a future version, just rename existing self or choose another variable name to alias the global object like how others did in case 1.
4. If implementation specified behavior is involved, any name other than self can lead to worse situation since only self has known use to be alias to global object. (check what Node.js have done explained for the previous question)
5. If existing code used the global in Node.js, then it has nothing to do with this to-be self, since they are two completely different being.

BTW, https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/520/ shows 404 for now, what was the result?

[GreLI]

Since global isn't really global, but depends on context, frames, etc, may be should it called realm?

[sffc]

window is a noun. I like using a similar noun, like globe (suggested by epeters3) or universe.

[ljharb]

@sffc "the global" is a noun too; despite originally being an adjective, like it or not it's been nouned (yes, "noun" has been verbed; and yes, so has "verbed") by the JS community.

[hollowdoor]

I don't think 'global' is arbitrary as it matches the usage, and means what everyone's been saying since programming was a thing even in other languages. Maybe that's just my opinion. I don't know. Compat is king as well so relevant semantics could be moot. Though the same argument could be made for code base semantics being arbitrary.

What about calling the top level 'arch', 'prime', or 'main'? I don't know if those could be considered arbitrary, but they certainly have a ring to them. I like 'arch' in particular which is also a noun, and adjective. Arch variables?

A single letter would also be viable like 'g', or 'G', or perhaps 'z' the uncommon letter. 'zoo' would provide some entertainment value, and is an occasionally applicable metaphor. :)

Sorry for butting in this late in the game.

BTW 'self' seems semantically odd to me. Is 'global' supposed to be scoped to the current frame like 'window'? 'universe' like @sffc suggests sounds nifty.

[EthanRutherford]

top seems like it would make sense (as in, the top-level scope)

[dcgudeman]

@ljharb If people like global because it is semantically clear why not take it a step further and just call it globalScope

[ljharb]

@dcgudeman that's not clear; it's the global object/global this value, it's not a scope - the line gets blurry when you're talking about global vars, sure, but it doesn't contain scope information (you can't see const values as properties of that object, for example).

[dcgudeman]

@ljharb That makes sense. So would a name like globalObject or globalThis work? Admittedly seeing the capital 'T' in globalThis makes me cringe, maybe thisGlobal would be easier to digest.

[ljharb]

It remains to be seen what will work.

Specific suggestions aren't really helpful at this stage, though.

[hollowdoor]

What is this stage? @ljharb

You said

We’re waiting on telemetry from browsers

But that was weeks ago. Is that still the current stage? I hope I don't come across as impatient. I'm just interested in the process.

[leobalter]

@hollowdoor There is no public update so far, and by public not even specific information I see shared within TC39.

Although, the public agenda already show @ljharb will present something new in the next TC39 meeting, happening at the end of July.

https:/tc39/agendas/blob/master/2018/07.md

I'm looking forward to it.

[ljharb]

@hollowdoor it’s taken well over a year so far, so “weeks” isn’t much :-)

[hollowdoor]

Right on. Maybe I'm a little too excited about this particular feature. :)

[chr1se]

..oops forgive my misunderstanding & thanks for the clarification
departing suggestions:

globals
shell
container

[demurgos]

Hey,
The infinite stream of name proposals in this issue gave me a great (?) idea. 😛

How about amending the proposal to specifically disable global on flickr? Windows 95 style:

Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away.

(Joel Spolsky)

I'm sure there won't be any downsides to this idea...

Edit: This is a joke, please don't do this.

[ljharb]

@demurgos flickr is just the largest case; https://bugzilla.mozilla.org/show_bug.cgi?id=1326032 was on a different site. Individual sites are symptomatic of a larger problem; it can't really be papered over in that way.

[demurgos]

@ljharb
I tried to hint it with smileys and punctuation, but my suggestion was just a joke: obviously it's not a tenable solution. But thanks for calling me out and clarifying it, sorry if it wasn't very constructive. I just wanted to lighten the mood a bit between the many comments asking for progress or throwing new names.

[domenic]

If people will forgive a bit more off-topic digression, they may enjoy perusing how a suggestion very similar to @demurgos's joke actually made its way into Chrome: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/events/event_target.cc?l=252&rcl=37b6757f5f82d379b43903728641081141f94217. (And indeed, will likely make its way into web standards.)

[andyearnshaw]

@domenic that seems similar to what I suggested earlier in the thread. @ljharb appears to have some disagreement with the solution linked to, though 😉