Why is this an error in IE11 and Pale Moon?
I reported a Javascript bug to the FreeNAS team on their bug tracker, related to their upcoming release which won't work due to a JS syntax error on some less common browsers, but I'm curious why it's an error.
The code snippet raises a pretty well-defined error on Win8.1 default browser (IE11) and Pale Moon (Firefox based) browsers, but no error on Firefox or Vivaldi (Chrome based). What does the code actually do, and why does it trigger a reserved word error/syntax error in these browsers?
The code is hard to trace, it looks like a webpack minified file and I'm not familiar enough with the base + build systems to follow where it ultimately originates before packing.
The relevant code snippet that triggers the error looks like this in the browser consoles:
webpackJsonp([20], {
... long list of function defs ...
BFiu: function(t, e, n) {
"use strict";
n.d(e, "a", function() {
return r
});
var o = n("HcJ8");
n.n(o);
let i = {
Queue: 0,
Uploading: 1,
Done: 2,
Cancelled: 3
};
i[i.Queue] = "Queue",
i[i.Uploading] = "Uploading",
i[i.Done] = "Done",
i[i.Cancelled] = "Cancelled";
class r {}
},
... more function defs ...
},
[0]);
According to the JS console, it's the line class r{} which causes a fatal syntax error in some browsers, and kills the GUI loading script. Pale Moon states that the problem is misuse of a reserved word "class", IE11 just points to the same word and reports a syntax error. But on other browsers it's fine.
Intuitively I would expect that reserved word misuse of such a key JS word would be fairly well-defined even across notoriously different browsers and JS engines (apparently not?), so I'm intrigued. What's going on?
Ideally also (if able to help), how can I find the upstream source for this code snippet, so I can take a look at its issue/bug tracker?
Source code: The code snippet comes from a file "main.57ebfd2da123881a1a70.bundle.js" in FreeNAS 11.2-RC2. I've traced it as far as line 69 of this file in the FreeNAS build/WebUI system, where the filename is referenced apparently when webpack builds it, but I can't work out how to track back to its origin, to see which module this snippet is from, or if there's an upstream bug report on whatever project the module came from.
javascript debugging webpack internet-explorer-11 palemoon
add a comment |
I reported a Javascript bug to the FreeNAS team on their bug tracker, related to their upcoming release which won't work due to a JS syntax error on some less common browsers, but I'm curious why it's an error.
The code snippet raises a pretty well-defined error on Win8.1 default browser (IE11) and Pale Moon (Firefox based) browsers, but no error on Firefox or Vivaldi (Chrome based). What does the code actually do, and why does it trigger a reserved word error/syntax error in these browsers?
The code is hard to trace, it looks like a webpack minified file and I'm not familiar enough with the base + build systems to follow where it ultimately originates before packing.
The relevant code snippet that triggers the error looks like this in the browser consoles:
webpackJsonp([20], {
... long list of function defs ...
BFiu: function(t, e, n) {
"use strict";
n.d(e, "a", function() {
return r
});
var o = n("HcJ8");
n.n(o);
let i = {
Queue: 0,
Uploading: 1,
Done: 2,
Cancelled: 3
};
i[i.Queue] = "Queue",
i[i.Uploading] = "Uploading",
i[i.Done] = "Done",
i[i.Cancelled] = "Cancelled";
class r {}
},
... more function defs ...
},
[0]);
According to the JS console, it's the line class r{} which causes a fatal syntax error in some browsers, and kills the GUI loading script. Pale Moon states that the problem is misuse of a reserved word "class", IE11 just points to the same word and reports a syntax error. But on other browsers it's fine.
Intuitively I would expect that reserved word misuse of such a key JS word would be fairly well-defined even across notoriously different browsers and JS engines (apparently not?), so I'm intrigued. What's going on?
Ideally also (if able to help), how can I find the upstream source for this code snippet, so I can take a look at its issue/bug tracker?
Source code: The code snippet comes from a file "main.57ebfd2da123881a1a70.bundle.js" in FreeNAS 11.2-RC2. I've traced it as far as line 69 of this file in the FreeNAS build/WebUI system, where the filename is referenced apparently when webpack builds it, but I can't work out how to track back to its origin, to see which module this snippet is from, or if there's an upstream bug report on whatever project the module came from.
javascript debugging webpack internet-explorer-11 palemoon
Theclasskeyword is not supported in ancient browsers like IE, that's all
– CertainPerformance
Nov 29 '18 at 0:01
Aha! Thank you! Followup question - how can I trace the originating project/module, wherever this code came from before webpacking, to see if it's been reported, or if it can be fixed upstream "at source"?
– Stilez
Nov 29 '18 at 0:04
I would recommend that the project maintainers simply use Babel to automatically transpile their code to ES5 (supported by IE), rather than use ES6+ syntax alone (which includesclassand many other things)
– CertainPerformance
Nov 29 '18 at 0:05
Thanks! I'm kind of hoping someone can figure a way to track down the relevant project maintainers for that code snippet, which looks like a 3rd party project. But this info is very helpful as-is.
– Stilez
Nov 29 '18 at 0:11
@ CertainPerformance - Can you post the above points as an answer? They solve the problem elegantly, but I can't mark them as doing so until you do :)
– Stilez
Nov 30 '18 at 4:23
add a comment |
I reported a Javascript bug to the FreeNAS team on their bug tracker, related to their upcoming release which won't work due to a JS syntax error on some less common browsers, but I'm curious why it's an error.
The code snippet raises a pretty well-defined error on Win8.1 default browser (IE11) and Pale Moon (Firefox based) browsers, but no error on Firefox or Vivaldi (Chrome based). What does the code actually do, and why does it trigger a reserved word error/syntax error in these browsers?
The code is hard to trace, it looks like a webpack minified file and I'm not familiar enough with the base + build systems to follow where it ultimately originates before packing.
The relevant code snippet that triggers the error looks like this in the browser consoles:
webpackJsonp([20], {
... long list of function defs ...
BFiu: function(t, e, n) {
"use strict";
n.d(e, "a", function() {
return r
});
var o = n("HcJ8");
n.n(o);
let i = {
Queue: 0,
Uploading: 1,
Done: 2,
Cancelled: 3
};
i[i.Queue] = "Queue",
i[i.Uploading] = "Uploading",
i[i.Done] = "Done",
i[i.Cancelled] = "Cancelled";
class r {}
},
... more function defs ...
},
[0]);
According to the JS console, it's the line class r{} which causes a fatal syntax error in some browsers, and kills the GUI loading script. Pale Moon states that the problem is misuse of a reserved word "class", IE11 just points to the same word and reports a syntax error. But on other browsers it's fine.
Intuitively I would expect that reserved word misuse of such a key JS word would be fairly well-defined even across notoriously different browsers and JS engines (apparently not?), so I'm intrigued. What's going on?
Ideally also (if able to help), how can I find the upstream source for this code snippet, so I can take a look at its issue/bug tracker?
Source code: The code snippet comes from a file "main.57ebfd2da123881a1a70.bundle.js" in FreeNAS 11.2-RC2. I've traced it as far as line 69 of this file in the FreeNAS build/WebUI system, where the filename is referenced apparently when webpack builds it, but I can't work out how to track back to its origin, to see which module this snippet is from, or if there's an upstream bug report on whatever project the module came from.
javascript debugging webpack internet-explorer-11 palemoon
I reported a Javascript bug to the FreeNAS team on their bug tracker, related to their upcoming release which won't work due to a JS syntax error on some less common browsers, but I'm curious why it's an error.
The code snippet raises a pretty well-defined error on Win8.1 default browser (IE11) and Pale Moon (Firefox based) browsers, but no error on Firefox or Vivaldi (Chrome based). What does the code actually do, and why does it trigger a reserved word error/syntax error in these browsers?
The code is hard to trace, it looks like a webpack minified file and I'm not familiar enough with the base + build systems to follow where it ultimately originates before packing.
The relevant code snippet that triggers the error looks like this in the browser consoles:
webpackJsonp([20], {
... long list of function defs ...
BFiu: function(t, e, n) {
"use strict";
n.d(e, "a", function() {
return r
});
var o = n("HcJ8");
n.n(o);
let i = {
Queue: 0,
Uploading: 1,
Done: 2,
Cancelled: 3
};
i[i.Queue] = "Queue",
i[i.Uploading] = "Uploading",
i[i.Done] = "Done",
i[i.Cancelled] = "Cancelled";
class r {}
},
... more function defs ...
},
[0]);
According to the JS console, it's the line class r{} which causes a fatal syntax error in some browsers, and kills the GUI loading script. Pale Moon states that the problem is misuse of a reserved word "class", IE11 just points to the same word and reports a syntax error. But on other browsers it's fine.
Intuitively I would expect that reserved word misuse of such a key JS word would be fairly well-defined even across notoriously different browsers and JS engines (apparently not?), so I'm intrigued. What's going on?
Ideally also (if able to help), how can I find the upstream source for this code snippet, so I can take a look at its issue/bug tracker?
Source code: The code snippet comes from a file "main.57ebfd2da123881a1a70.bundle.js" in FreeNAS 11.2-RC2. I've traced it as far as line 69 of this file in the FreeNAS build/WebUI system, where the filename is referenced apparently when webpack builds it, but I can't work out how to track back to its origin, to see which module this snippet is from, or if there's an upstream bug report on whatever project the module came from.
javascript debugging webpack internet-explorer-11 palemoon
javascript debugging webpack internet-explorer-11 palemoon
edited Nov 29 '18 at 0:01
Stilez
asked Nov 28 '18 at 23:59
StilezStilez
258210
258210
Theclasskeyword is not supported in ancient browsers like IE, that's all
– CertainPerformance
Nov 29 '18 at 0:01
Aha! Thank you! Followup question - how can I trace the originating project/module, wherever this code came from before webpacking, to see if it's been reported, or if it can be fixed upstream "at source"?
– Stilez
Nov 29 '18 at 0:04
I would recommend that the project maintainers simply use Babel to automatically transpile their code to ES5 (supported by IE), rather than use ES6+ syntax alone (which includesclassand many other things)
– CertainPerformance
Nov 29 '18 at 0:05
Thanks! I'm kind of hoping someone can figure a way to track down the relevant project maintainers for that code snippet, which looks like a 3rd party project. But this info is very helpful as-is.
– Stilez
Nov 29 '18 at 0:11
@ CertainPerformance - Can you post the above points as an answer? They solve the problem elegantly, but I can't mark them as doing so until you do :)
– Stilez
Nov 30 '18 at 4:23
add a comment |
Theclasskeyword is not supported in ancient browsers like IE, that's all
– CertainPerformance
Nov 29 '18 at 0:01
Aha! Thank you! Followup question - how can I trace the originating project/module, wherever this code came from before webpacking, to see if it's been reported, or if it can be fixed upstream "at source"?
– Stilez
Nov 29 '18 at 0:04
I would recommend that the project maintainers simply use Babel to automatically transpile their code to ES5 (supported by IE), rather than use ES6+ syntax alone (which includesclassand many other things)
– CertainPerformance
Nov 29 '18 at 0:05
Thanks! I'm kind of hoping someone can figure a way to track down the relevant project maintainers for that code snippet, which looks like a 3rd party project. But this info is very helpful as-is.
– Stilez
Nov 29 '18 at 0:11
@ CertainPerformance - Can you post the above points as an answer? They solve the problem elegantly, but I can't mark them as doing so until you do :)
– Stilez
Nov 30 '18 at 4:23
The
class keyword is not supported in ancient browsers like IE, that's all– CertainPerformance
Nov 29 '18 at 0:01
The
class keyword is not supported in ancient browsers like IE, that's all– CertainPerformance
Nov 29 '18 at 0:01
Aha! Thank you! Followup question - how can I trace the originating project/module, wherever this code came from before webpacking, to see if it's been reported, or if it can be fixed upstream "at source"?
– Stilez
Nov 29 '18 at 0:04
Aha! Thank you! Followup question - how can I trace the originating project/module, wherever this code came from before webpacking, to see if it's been reported, or if it can be fixed upstream "at source"?
– Stilez
Nov 29 '18 at 0:04
I would recommend that the project maintainers simply use Babel to automatically transpile their code to ES5 (supported by IE), rather than use ES6+ syntax alone (which includes
class and many other things)– CertainPerformance
Nov 29 '18 at 0:05
I would recommend that the project maintainers simply use Babel to automatically transpile their code to ES5 (supported by IE), rather than use ES6+ syntax alone (which includes
class and many other things)– CertainPerformance
Nov 29 '18 at 0:05
Thanks! I'm kind of hoping someone can figure a way to track down the relevant project maintainers for that code snippet, which looks like a 3rd party project. But this info is very helpful as-is.
– Stilez
Nov 29 '18 at 0:11
Thanks! I'm kind of hoping someone can figure a way to track down the relevant project maintainers for that code snippet, which looks like a 3rd party project. But this info is very helpful as-is.
– Stilez
Nov 29 '18 at 0:11
@ CertainPerformance - Can you post the above points as an answer? They solve the problem elegantly, but I can't mark them as doing so until you do :)
– Stilez
Nov 30 '18 at 4:23
@ CertainPerformance - Can you post the above points as an answer? They solve the problem elegantly, but I can't mark them as doing so until you do :)
– Stilez
Nov 30 '18 at 4:23
add a comment |
1 Answer
1
active
oldest
votes
class is an ES6 (ES2015) keyword which works on most browsers, but not on ancient ones like IE (last version of IE, IE11, was released in 2013). Although PaleMoon states they're mostly ES6 compliant, it doesn't appear to support class yet - the founder's opinion is:
Classes in JS are simply a really, really bad idea, trying to enforce OO structures from a different language to something that is simply not designed to do things that way.
There's also no reason to use classes per se, as anything done with classes can be done with basic and completely compatible use of JS prototypes. Prototyping is there for a reason; use it.
The general solution for devs who use "class" syntax and want their code to be compatible with IE, PaleMoon, and other non-standards-compliant browsers is to integrate Babel into their build process, which can automatically transpile a codebase's ES6+ syntax (including the "class" keyword) into ES5 syntax. For example:
class Foo {
}
turns into
"use strict";
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }
var Foo = function Foo() {
_classCallCheck(this, Foo);
};
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53529931%2fwhy-is-this-an-error-in-ie11-and-pale-moon%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
class is an ES6 (ES2015) keyword which works on most browsers, but not on ancient ones like IE (last version of IE, IE11, was released in 2013). Although PaleMoon states they're mostly ES6 compliant, it doesn't appear to support class yet - the founder's opinion is:
Classes in JS are simply a really, really bad idea, trying to enforce OO structures from a different language to something that is simply not designed to do things that way.
There's also no reason to use classes per se, as anything done with classes can be done with basic and completely compatible use of JS prototypes. Prototyping is there for a reason; use it.
The general solution for devs who use "class" syntax and want their code to be compatible with IE, PaleMoon, and other non-standards-compliant browsers is to integrate Babel into their build process, which can automatically transpile a codebase's ES6+ syntax (including the "class" keyword) into ES5 syntax. For example:
class Foo {
}
turns into
"use strict";
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }
var Foo = function Foo() {
_classCallCheck(this, Foo);
};
add a comment |
class is an ES6 (ES2015) keyword which works on most browsers, but not on ancient ones like IE (last version of IE, IE11, was released in 2013). Although PaleMoon states they're mostly ES6 compliant, it doesn't appear to support class yet - the founder's opinion is:
Classes in JS are simply a really, really bad idea, trying to enforce OO structures from a different language to something that is simply not designed to do things that way.
There's also no reason to use classes per se, as anything done with classes can be done with basic and completely compatible use of JS prototypes. Prototyping is there for a reason; use it.
The general solution for devs who use "class" syntax and want their code to be compatible with IE, PaleMoon, and other non-standards-compliant browsers is to integrate Babel into their build process, which can automatically transpile a codebase's ES6+ syntax (including the "class" keyword) into ES5 syntax. For example:
class Foo {
}
turns into
"use strict";
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }
var Foo = function Foo() {
_classCallCheck(this, Foo);
};
add a comment |
class is an ES6 (ES2015) keyword which works on most browsers, but not on ancient ones like IE (last version of IE, IE11, was released in 2013). Although PaleMoon states they're mostly ES6 compliant, it doesn't appear to support class yet - the founder's opinion is:
Classes in JS are simply a really, really bad idea, trying to enforce OO structures from a different language to something that is simply not designed to do things that way.
There's also no reason to use classes per se, as anything done with classes can be done with basic and completely compatible use of JS prototypes. Prototyping is there for a reason; use it.
The general solution for devs who use "class" syntax and want their code to be compatible with IE, PaleMoon, and other non-standards-compliant browsers is to integrate Babel into their build process, which can automatically transpile a codebase's ES6+ syntax (including the "class" keyword) into ES5 syntax. For example:
class Foo {
}
turns into
"use strict";
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }
var Foo = function Foo() {
_classCallCheck(this, Foo);
};
class is an ES6 (ES2015) keyword which works on most browsers, but not on ancient ones like IE (last version of IE, IE11, was released in 2013). Although PaleMoon states they're mostly ES6 compliant, it doesn't appear to support class yet - the founder's opinion is:
Classes in JS are simply a really, really bad idea, trying to enforce OO structures from a different language to something that is simply not designed to do things that way.
There's also no reason to use classes per se, as anything done with classes can be done with basic and completely compatible use of JS prototypes. Prototyping is there for a reason; use it.
The general solution for devs who use "class" syntax and want their code to be compatible with IE, PaleMoon, and other non-standards-compliant browsers is to integrate Babel into their build process, which can automatically transpile a codebase's ES6+ syntax (including the "class" keyword) into ES5 syntax. For example:
class Foo {
}
turns into
"use strict";
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }
var Foo = function Foo() {
_classCallCheck(this, Foo);
};
answered Nov 30 '18 at 4:54
CertainPerformanceCertainPerformance
97.3k165887
97.3k165887
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53529931%2fwhy-is-this-an-error-in-ie11-and-pale-moon%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The
classkeyword is not supported in ancient browsers like IE, that's all– CertainPerformance
Nov 29 '18 at 0:01
Aha! Thank you! Followup question - how can I trace the originating project/module, wherever this code came from before webpacking, to see if it's been reported, or if it can be fixed upstream "at source"?
– Stilez
Nov 29 '18 at 0:04
I would recommend that the project maintainers simply use Babel to automatically transpile their code to ES5 (supported by IE), rather than use ES6+ syntax alone (which includes
classand many other things)– CertainPerformance
Nov 29 '18 at 0:05
Thanks! I'm kind of hoping someone can figure a way to track down the relevant project maintainers for that code snippet, which looks like a 3rd party project. But this info is very helpful as-is.
– Stilez
Nov 29 '18 at 0:11
@ CertainPerformance - Can you post the above points as an answer? They solve the problem elegantly, but I can't mark them as doing so until you do :)
– Stilez
Nov 30 '18 at 4:23