You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CanJS seems to be adding symbols to global prototypes, which -- in a scenario with polyfills using Babel for backwards compatibility -- triggers zloirock/core-js#735 .
The latter cannot be reliably worked around by means other than not placing symbols on globals.
In scenarios where CanJS has to add symbols to global prototypes, it should probably harden whatever checks it has in place to verify that it's dealing with native Symbol and not the CoreJS polyfill. If it's dealing with the polyfill, it should always fall back on the not-a-symbol-but-a-string-key approach.
When an application hits a bad use of a symbol that triggers above CoreJS problem, it leads to a complete breakdown as a stack overflow basically means: end-of-story.
This was found with the can@5.33.2 package but is probably present in 6.x as well.
As this is a real showstopper I'd also really appreciate a coherent patch to the 5.x versions as well.
[EDIT]
Seems this could be worked around by modifying the supportsNativeSymbols function in the can-symbol package, like so:
varsupportsNativeSymbols=(function(){varsymbolExists=typeofSymbol!=="undefined"&&typeofSymbol.for==="function"// The following are additions introduced by the CoreJS polyfill// that breaks certain cases in CanJS.&&!("useSetter"inSymbol||"useSimple"inSymbol);if(!symbolExists){returnfalse;}varsymbol=Symbol("a symbol for testing symbols");returntypeofsymbol==="symbol";}());
[EDIT 2]
This works, but the exact same check is duplicated in the can-reflect package under ./reflections/type/type where it also needs to be amended.
(Actually; as can-reflect already takes a dependency on can-symbol the latter should probably export the result of the native symbol test so that the former can use it...)
[EDIT 3]
Doesn't actually work correctly.
Looks like CoreJS adds those two methods to the NATIVE Symbol as well. >_<
The text was updated successfully, but these errors were encountered:
rjgotten
changed the title
BUG | Out of stack space error in IE 11 with polyfilled symbols
BUG/CRQ | Harden Symbol polyfill detection and avoid out of stack space error in IE 11 with polyfilled symbols
Jan 27, 2020
varsupportsNativeSymbols=(function(){varsymbolExists=typeofSymbol!=="undefined"&&typeofSymbol.for==="function"&&!Symbol.sham;if(!symbolExists){returnfalse;}varsymbol=Symbol("a symbol for testing symbols");returntypeofsymbol==="symbol";}());
CoreJS only adds sham: true to its own fake symbol.
CanJS seems to be adding symbols to global prototypes, which -- in a scenario with polyfills using Babel for backwards compatibility -- triggers zloirock/core-js#735 .
The latter cannot be reliably worked around by means other than not placing symbols on globals.
In scenarios where CanJS has to add symbols to global prototypes, it should probably harden whatever checks it has in place to verify that it's dealing with native Symbol and not the CoreJS polyfill. If it's dealing with the polyfill, it should always fall back on the not-a-symbol-but-a-string-key approach.
When an application hits a bad use of a symbol that triggers above CoreJS problem, it leads to a complete breakdown as a stack overflow basically means: end-of-story.
This was found with the
can@5.33.2
package but is probably present in 6.x as well.As this is a real showstopper I'd also really appreciate a coherent patch to the 5.x versions as well.
[EDIT]
Seems this could be worked around by modifying the
supportsNativeSymbols
function in thecan-symbol
package, like so:[EDIT 2]
This works, but the exact same check is duplicated in the
can-reflect
package under./reflections/type/type
where it also needs to be amended.(Actually; as
can-reflect
already takes a dependency oncan-symbol
the latter should probably export the result of the native symbol test so that the former can use it...)[EDIT 3]
Doesn't actually work correctly.
Looks like CoreJS adds those two methods to the NATIVE Symbol as well. >_<
The text was updated successfully, but these errors were encountered: