opened
evilpie
username_0
See [bug 1325907 ](https://bugzilla.mozilla.org/show_bug.cgi?id=1325907). Just the existence of `global` flickr.com. This seems to be caused by code in the popular moment/moment library.
global is not webcompatible
issue
created
ljharb
username_1
The referenced code - https://github.com/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 :-/
comment
created
ziyunfei
username_2
The moment.js code is warped in a YUI module:
```
YUI.add("moment", function(e, t) {
  alert(this === global) // false 
}, "@VERSION@")
```
![image](https://cloud.githubusercontent.com/assets/1276859/21536938/a5864d66-cdc4-11e6-95f0-c245aaee875c.png)
comment
created
ljharb
username_1
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`.

@username_0 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.
comment
created
ziyunfei
username_2
The `typeof global` checking had already been removed from new versions of moment.js.
comment
created
ljharb
username_1
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. @username_0, if this happens, would we be able to try this again in Firefox?
comment
created
jswalden
username_3
Unless I'm misreading the code (entirely possible), https://github.com/tc39/proposal-global/issues/20#issuecomment-269586160 looks wrong to me.  Flickr's moment.js code is identical to that on trunk, and that's been on trunk since https://github.com/moment/moment/commit/1601cb1dd7b14277ba8b00cb2ece3ce637923080 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 and removing parentheses that aren't necessary by language precedence order.

The issue here is purely that Flickr's embedding moment.js code, that uses `this` presuming it's the global object, in a context where `this` is not the global object.
comment
created
ljharb
username_1
@username_3 thanks, I think your conclusion is correct.
comment
created
ljharb
username_1
Another example has popped up in Firefox: [bug 1326032](https://bugzilla.mozilla.org/show_bug.cgi?id=1326032)
comment
created
littledan
username_4
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.
comment
created
miketaylr
username_5
Also, JIRA, in https://bugzilla.mozilla.org/show_bug.cgi?id=1328218 (due to moment.js).
comment
created
evilpie
username_0
I should mention we removed `global` from Nightly again.
comment
created
nt1m
username_6
@username_0 : 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
comment
created
evilpie
username_0
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.
comment
created
ljharb
username_1
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.
comment
created
rjgotten
username_7
You are misreading the code. Those lines are not at all there in trunk, i.e., in https://github.com/moment/moment/blob/master/moment.js

They're there in [version 2.0.9](https://github.com/moment/moment/blob/2.9.0/moment.js) which was tagged 2015-01-02, but were removed when [version 2.10.2](https://github.com/moment/moment/blob/2.10.2/moment.js) which was tagged 2015-04-09, introduced a UMD wrapper.

So yes; this would be resolved by Yahoo, Flickr, etc. updating their codebase.
comment
created
littledan
username_4
@username_1 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?
comment
created
targos
username_8
I can try to add `self` to Node and see if CITGM breaks.
comment
created
ljharb
username_1
@username_4 I won't be continuing the proposal if it's named `self` - @username_8, if that is easy that would be helpful, but only to disqualify it.
comment
created
ljharb
username_1
Regardless 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, or to namespace it under a new or existing web-compatible top-level name.
comment
created
michaelficarra
username_9
It looks like we have reason to introduce `System.global` after all.
comment
created
leobalter
username_10
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.
comment
created
jakub-g
username_11
`__global__` seems rather safe IMO, and in line with stuff like`__proto__`. Though indeed it looks ugly.
comment
created
ljharb
username_1
@username_8 it looked like the CIGTM run failed a bunch of the jobs?
comment
created
ljharb
username_1
@username_10 `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.
comment
created
kdzwinel
username_12
FYI [Safari Technology Preview 21](https://webkit.org/blog/7265/release-notes-for-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.
comment
created
ljharb
username_1
@username_12 can you comment on the [firefox bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1328218) related to jira? It should be broken in both places if this is indeed the cause.
comment
created
miketaylr
username_5
And backed out: https://bugs.webkit.org/show_bug.cgi?id=166915
comment
created
ljharb
username_1
(Turns out it requires a newer Jira version to get the failure)
comment
created
andyearnshaw
username_13
Is it feasible to continue with `global`, but have vendors apply a patch to the offending moment.js scripts?  For instance, if they could recognise the script and introduce a scope layer at the top level of the script where `global` is undefined?  From what I understand, moment.js was the only reported incompatibility, so this seems like it may be worth trying to "un-stall" this feature.

I realise there's no precedent for this when introducing a new global property, but I know that vendors have patched some JS scripts before.
comment
created
ljharb
username_1
@username_13 browsers have indicated that it's not feasible. (I'm also not aware of browsers ever "patching" code on websites in the way you're indicating, do you have any links?)
comment
created
andyearnshaw
username_13
...but this isn't really the same thing.
comment
created
michaelficarra
username_9
I mean, if all of the offending scripts have the same hash, the browser could just replace them with a compatible but fixed version. All browsers already have a mechanism for hashing scripts if they support CSP or SRI. Seems worth suggesting to implementors.
comment
created
mgol
username_14
@username_9 That won't work for people using bundlers like Webpack or Browserify or if they minify themselves etc.
comment
created
miketaylr
username_5
That won't work for the simple reason that browsers don't want to be in the business of being a CDN for up to date JS lib versions.
comment
created
littledan
username_4
Different browsers will have different policies here, but as a way of rolling out a new feature, I think this is pretty safely a dead end.
comment
created
syg
username_15
Did we ever bikeshed new names and agree on the next name for browsers to play whack-a-mole with?
comment
created
ljharb
username_1
Not yet. Mainly we need a browser to volunteer to try one, and I can pick from the bikeshed list.
comment
created
littledan
username_4
@username_1 I think if you go and pick something, and get agreement from everybody that it'd be a good name if it works, then browsers might be more excited to try it; it can be hard to preemptively volunteer to ship in the absence of an agreed-on proposal.
comment
created
ljharb
username_1
Sounds good; I'll get some consensus this week and settle on our next attempt.
comment
created
hax
username_16
Any update?
comment
created
ljharb
username_1
No update yet.
comment
created
JakeChampion
username_17
How about we use `System.global`?
comment
created
littledan
username_4
We don't have a System object yet. System.global has been proposed in TC39, but IIRC some committee members objected that global is a little to small to justify System itself. Plus, such a long name might not be very attractive to use.
comment
created
littledan
username_4
Due to this issue, the global proposal does not seem like it will proceed to Stage 4 in this form. Looking at this repository, I'm having trouble finding any indication outside of this bug that the name `global` is not going to be used going forward. I think it'd be best if the README.md and spec had a note mentioning this fact, and replacing `global` with a clearly unusable placeholder. @phoddie mentioned to me that Moddable has implemented this proposal, unaware of the specification status (even if it might be fine for them to ship this long term, like Node does).
comment
created
ljharb
username_1
That sounds like a good idea. I'll update the readme and spec with a placeholder.

Moddable is a rare event; a new engine that wasn't present during the committee meetings for this proposal :-)
comment
created
littledan
username_4
Actually I think there are a lot of people who look at proposal repositories who can't come to meetings. For one, engines have multiple people working on them; there are also popular polyfills without committee representation. Proposal repositories should explain themselves well for all of them.

I'd recommend writing these warnings in bigger letters and actually scratching out mentions of global. People could gloss over these notes as they are written now. Also, I wouldn't mind if this were somehow noted in the proposals repository that it is not ready.
comment
created
aciccarello
username_18
comment
created
ljharb
username_1
All of the 4 browsers have existing bugs filed that say to hold off implementing; there's really only two popular polyfills i know of, one's mine, and the other's author follows this repo closely.

This seems like an overabundance of caution to me; non-browsers always have to be aware of the web compatibility risk in stage 3 (perhaps the process document needs to indicate that more clearly?).
comment
created
littledan
username_4
Thanks, I appreciate the follow-on change. My experience so far with TC39 is that there are lots of people looking at these proposals, different people are going to look at different things, and it'll be helpful to some people who end up skimming your explainer here that the current status is more clear (it's not like I do a perfect job of this myself).
comment
created
sag1v
username_19
Do we have to choose from the already existing list (`global`, `window`, `this`, `frame`...) ?
How about `root`?
comment
created
ljharb
username_1
No, we don’t have to choose one from an existing list.
comment
created
Kovensky
username_20
In the babel slack, I at one point suggested `realm`, as you have one global object per javascript Realm; but @username_1 thinks it's too obscure if you can't tell it's "the global" without needing this kind of background knowledge.
comment
created
ljharb
username_1
I'm pretty strongly only going to go forward with an identifier that includes the word "global".

However, due to web compatibility issues, the only productive suggestions are ones that accompany actual browser usage metrics.
comment
created
sag1v
username_19
@username_1 Is that an answer to my suggestion regarding `root` being out of the question? :)
comment
created
b-strauss
username_21
why not `globalObject`?

https://developer.mozilla.org/en-US/docs/Glossary/Global_object
comment
created
andyearnshaw
username_13
Having the type in the name, `globalObject`, just seems too weird and ignoring existing naming conventions.  For instance, we don't have `thisValue`, `parseIntFunction`, `argumentsList`, `ArrayConstructor`, etc.

I liked `System.global`, but `System` was thrown out so it seems silly to add a new namespace just for `global`.  How about `gIobal`? Then we can pretend that's how it was spelled all along :grin:
comment
created
b-strauss
username_21
`DOMStringList`, `Float32Array`, `NodeList`, `ArrayBuffer`

😝
comment
created
Kovensky
username_20
Kind of the problem here seems to be that no name for global will be accepted other than `global`.

My self-righteousness leans more towards blaming JIRA/flickr though 😡
comment
created
ljharb
username_1
I have a list of candidates, but I’d prefer not to advertise them until browsers have helped me ascertain web compat risk.

Thanks for your suggestions, but i doubt they’ll end up being helpful (since we probably already have the good ones on our list).
comment
created
littledan
username_4
@username_1 You might have trouble convincing browsers to ship your new names before getting committee and community feedback on them.
comment
created
jswalden
username_3
I assume his intent is to keep the candidates on the down-low until there seems plausible evidence they can be shipped, so we don't have another case where some JS library over-eagerly starts trying to monkeypatch and ends up inadvertently poisoning the well in advance of some implementation actually making the change.  That is, I assume feedback will happen at some point -- just very carefully.
comment
created
andyearnshaw
username_13
Thanks for the update, I'm guessing `gIobal` is totally on the list but I understand if you can neither confirm nor deny 😁
comment
created
mgol
username_14
How about GLOBAL or Global?
-- 
Michał Gołębiowski-Owczarek
comment
created
ljharb
username_1
@username_4 the reflector already has a thread for that, where results will be discussed once i have them.
comment
created
michaelficarra
username_9
@username_14 `globał`?
comment
created
georgir
username_22
Object.global
comment
created
benwiley4000
username_23
"Globalism"
comment
created
rbuckton
username_24
@username_1 have you considered using a meta-property like `import.global`?
comment
created
epeters3
username_25
Is `globe` out of the question?
comment
created
benwiley4000
username_23
Perhaps there's a more diplomatic way of putting this, but has any consideration been paid to just pushing this through as-is and warning sites like Flickr and Jira to change their code, since they have plenty of highly paid developers whose job it is to respond to API changes?

All the non-`global` solutions proposed have sounded bad. Writing code which hinges on the assumption that a word - one as predictably-extant-in-the-future as `global`  - would *not* exist in the web client - was inadvisable. This shouldn't be everyone's problem. Everyone else sane in the world has been writing code that merely checks if `window` exists, since there's no foreseeable future where a such-named, globally-accessible object would exist in Node.js *without* emulating a browser API.
comment
created
Kovensky
username_20
IIUC, the problem with Jira is not that it is a website, but that it is a web application that is sold, packaged, to corporations; and the problem is in a version of Jira that is no longer being updated.
comment
created
doodadjs
username_26
What about my "application/javascript.2" idea, i.e. having a JS2 for breaking changes ?
comment
created
ljharb
username_1
We won’t break the web; no consideration will be given to doing that.

No English word is more important than keeping sites working for human beings, nor will it ever be.

We will find a word that works. Relax, be patient, settle down - something palatable will end up being feasible. It’ll be ok.
comment
created
zloirock
username_27
@username_1 this issue was opened already 1.5 years ago. In this and related threads, we have some alternatives. Maybe makes sense to choose something instead of being patient? It's just a variable name.
comment
created
ljharb
username_1
There’s a balance here between forward progress, and not using up browser goodwill.

We’re waiting on telemetry from browsers; after which we will, indeed, just pick a name.
comment
created
benwiley4000
username_23
@username_1 if you intend to call it "breaking the web" then of course I can't agree with that! 😄

I think your opinion is better than mine. Ultimately it probably is better practice not to overload `global` with new meaning and to come up with a new platform-independent name instead.

It's just the idea of Jira of all things blocking the progression of web, that gives me trouble sleeping at night. 😉
comment
created
rjgotten
username_7
Then it's not a matter of 'breaking the web' but a matter of breaking a poorly written application.
Tough luck for the companies that bought an old version; maybe they should consider upgrading or maybe they should demand a patch for their paid-for product.
comment
created
ljharb
username_1
The web consists of many things, including poorly written applications, and we won’t break users of poorly written applications either.
comment
created
Jamesernator
username_28
In this case I think it's fine to change the name of global as it's fairly easy to do and doesn't really matter.

But saying "we won't break users of poorly written applications" seems like a dangerous statement as it seems to suggest that if an application did something crazy like `if (Reflect.ownKeys(Array.prototype).length > 32) { doSomething() }` and forgot to update it if the number ever changed then the TC39 wouldn't add new Array methods ever in risk of breaking that specific site. Obviously that example probably isn't in use anywhere, but I'm sure there's fragile code that could break on similarly trivial additions to the language (*especially* new globals via `if (typeof someGlobal === 'undefined') { var someGlobal = ... }`).

It would be nice if there was a clearer definition of what is sufficiently important not to break given a proposal. e.g. Are 1000 users enough? Single bug reports in Nightly builds of browsers? Internal tools? etc
comment
created
deecewan
username_29
what's the threshold on this? There have got to be a million websites that have used some bad practice that will inevitably be broken by some update in the future, such as modify Array's prototype (`smoosh`).

Surely there has to be a middle ground between maintaining compat and progress?
comment
created
ljharb
username_1
@username_29 "progress" isn't measured by "keeping an arbitrary english word"; see https://github.com/tc39/proposal-global/issues/20#issuecomment-379134247 and earlier comments.
comment
created
deecewan
username_29
i meant more broadly than the word that is used, but I take your point. I guess what I'm getting at is that there are going to be people who aren't actively involved in the community/don't see these announcements who will have, at one point or another, written some code that may be broken by a proposal, and those voices won't be heard.

what's the threshold on 'number of people affected'? because it currently seems to be 'your voice matters if it's loud enough'.

If there is a better forum for this question, please direct me there.
comment
created
ljharb
username_1
When code is broken in a browser, hopefully someone files a bug report to that browser - that’s generally how the committee learns of the breakage. I’m not sure it’s a matter of a threshold (not that we have concrete criteria anywhere), but more a matter of evaluating any reports on a case by case basis.
comment
created
sag1v
username_19
Is `_global` or `_global_` is out of the question?
comment
created
ljharb
username_1
@username_19 there’s precedent for `__global__` but the aesthetics of that aren’t what I’d call “likely to satisfy the committee”, nor myself.
comment
created
ljharb
username_1
@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.
comment
created
rjgotten
username_7
You're expecting average web-users to file a bug report citing a broken API?
Or you're expecting developers to file a bug report with the browser, rather than the broken library?
comment
created
Licshee
username_30
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://github.com/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.
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 `self`s 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 method.
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, except 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
`global` in Node.js is a completely different thing, it will cause compatibility problems -- or at least Node.js users still have to use something like `self`.
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 simplify 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?
comment
created
GreLI
username_31
Since `global` isn't really global, but depends on context, frames, etc, may be should it called `realm`?
comment
created
sffc
username_32
`window` is a noun.  I like using a similar noun, like `globe` (suggested by username_25) or `universe`.
comment
created
ljharb
username_1
@username_32 "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.
comment
created
hollowdoor
username_33
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 @username_32  suggests sounds nifty.
comment
created
EthanRutherford
username_34
`top` seems like it would make sense (as in, the top level scope)
comment
created
dcgudeman
username_35
If people like `global` because it is semantically clear why not take it a step further and just call it `globalScope`
comment
created
ljharb
username_1
@username_35 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).
comment
created
dcgudeman
username_35
@username_1 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.
comment
created
ljharb
username_1
It remains to be seen what will work.

Specific suggestions aren't really helpful at this stage, though.
comment
created
hollowdoor
username_33
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.
comment
created
leobalter
username_10
@username_33 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 @username_1 will present something new in the next TC39 meeting, happening at the end of July.

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

I'm looking forward to it.
comment
created
ljharb
username_1
@username_33 it’s taken well over a year so far, so “weeks” isn’t much :-)
comment
created
hollowdoor
username_33
Right on. Maybe I'm a little too excited about this particular feature. :)
comment
created
chr1se
username_36
**var** foo = 10;
**let** foo = 20;

following the established 3 letter pattern, how is:
**gbl** foo = 30;
comment
created
ljharb
username_1
@username_36 i think you've misunderstood the entire purpose for the proposal - it doesn't deal with creating or reading global variables, it solely creates a single global variable that provides access to the global `this` value.
comment
created
chr1se
username_36
..oops forgive my misunderstanding & thanks for the clarification
departing suggestions:

`globals` 
`shell`  
`container`
comment
created
ljharb
username_1
@username_37 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.
comment
created
demurgos
username_37
@username_1 
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.
comment
created
domenic
username_38
If people will forgive a bit more off-topic digression, they may enjoy perusing how a suggestion very similar to @username_37'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.)
comment
closed
ljharb
username_1
issue