global object when window.global is defined

[yanatan16]

It seems that the global object can be window.global as opposed to window when it exists. This is a problem when some third party javascript decides to insert <div id="global">, and now two scripts can't refer to the same global object.

[jmm]

Thanks for the report. Maybe global should only be allowed to be the global object when ! window.

[JamesKyburz]

Or maybe adding a check that global.appendChild is not defined

[jmm]

@JamesKyburz Thanks for the suggestion. I was also wondering if a more specific test would make sense, but I was thinking of going the other way, like maybe checking for window.document or even window.document.implementation (or something), in case there's some plausible reason for there to be a global.window in node code. If the test was for global.appendChild, some random script could still break things by just setting window.global = {}, right?

[JamesKyburz]

@jmm true that. Maybe go with your first comment. A too big change could as you pointed out break stuff.

[nmn]

I think the convention of global being the global is pretty good and doesn't get in the way.
You can get to other global properties like document like so:
global.document

and in case there is an element with the id global, you can get to it by doing:

global.global

I think trying to access global properties directly is an anti-pattern anyway. Any global variables should be explicitly be accessed by using global.

[jmm]

@nmn I think you may have misinterpreted the issue. The problem is that if there is a window.global defined (which may happen just by virtue of a <whatever id="global"> element in the document) when the bundle executes, then inside the bundle global !== window, so there would be no global.document.

[nmn]

I think that in the bundle global === window. This is because global will be set as a variable by browserify and will mask the outer variable set by the DOM element. Further, I think global is set to the value of this so it should be foolproof.

[jmm]

@nmn Have you looked at the source? Or verified those theories by testing it?

[vvo]

It seems that the global object can be window.global as opposed to window when it exists. This is a problem when some third party javascript decides to insert

If the underlying website have a <div id=global> this happens too and then the global reference used in a browserified file will be useless.

Maybe The check for global should not be if (typeof global !== undefined) .. but rather if Object.prototype.hasOwnProperty.call(window, 'global') ..

what do you think?

[nmn]

@jmm Sorry, my knowledge about this was based on an old version of browserify.
However, I do think, that global should always be made to point to the window object. As other globals will always still be accessible.

[yanatan16]

@vvo I agree that if (typeof global !== undefined) is the culprit (here?). What if we reversed the order of ternary operators so that window was tested first, instead of global?

[vvo]

Would be better yes @yanatan16

[ltressens]

More than a year has passed before this issue was created.
Any fresh news ?

[acemtp]

Any news about this problem? We just spent 2 hours to find that one of our client had a <div id="global"> that broke sockjs because they use browserify...

[mrak]

We'd like to see this issue get fixed as well.

It's unfortunate in situations where your company or team does not have control over the DOM context that has an element with id="global" in which your code is running.

[jmm]

@ltressens @acemtp @mrak FWIW this would need to be fixed in insert-module-globals and, while there's been no recent news, most of the discussion is in browserify/insert-module-globals#48. As you can see, I think allowing things to break due to a random <someElement id="global"> is too fragile and something should be done.

[JoeZ99]

Looks like there's something missing that would satisfy collaboratos, so the browserify/insert-module-globals#48 PR doesn't get to be applied. This is somehow painful for all of us that are building libs to work in non-controlled DOM environments.

Has anyone at least come with some workaround in the meanwhile???