Why is this an error in IE11 and Pale Moon?












1















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.










share|improve this question

























  • 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











  • 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











  • @ 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


















1















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.










share|improve this question

























  • 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











  • 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











  • @ 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
















1












1








1








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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 29 '18 at 0:01







Stilez

















asked Nov 28 '18 at 23:59









StilezStilez

258210




258210













  • 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











  • 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











  • @ 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











  • 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













  • 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














1 Answer
1






active

oldest

votes


















2














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);
};





share|improve this answer
























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    2














    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);
    };





    share|improve this answer




























      2














      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);
      };





      share|improve this answer


























        2












        2








        2







        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);
        };





        share|improve this answer













        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);
        };






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 30 '18 at 4:54









        CertainPerformanceCertainPerformance

        97.3k165887




        97.3k165887
































            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Lallio

            Futebolista

            Jornalista