SpiderMonkey backports part 1 (general backports from SeaMonkey plus Nullish Coalescing)

[buttercookie42]

This is the start of my backporting series for SpiderMonkey.

This one is mainly based on most of the frontend backports from here, plus some additional things I either found by cross-referencing those commits with Bugzilla, or otherwise stumbled across, minus some things that would have required too much additional backports outside of the frontend part of SpiderMonkey (and a few patches turned out to have been already backported beforehand).

One thing I've intentionally left out due to add-on compatibility concerns is the removal of support for versioned JavaScript:

Support for legacy generators and a few other experimental SpiderMonkey features that weren't standardised and subsequently removed again post-Firefox 57 is currently gated on the declared JS version of a script. Internal browser code (including classic add-ons) gets all the features by default, whereas JavaScript on the web only gets the officially standardised feature set unless it explicitly declares a corresponding version. If we remove this mechanism, then

1. unconditionally enabling legacy generators for everybody apparently breaks some web pages that use yield as a class/variable/… name
2. unconditionally disabling legacy generators would require auditing our own browser code in that regard, plus it would definitively break some add-ons
3. the workaround employed by SeaMonkey of using isProbablySystemOrAddonCode instead of the JS version turns out to not actually cover all add-on code, e.g. a classic add-on loading a XUL overlay which in turns loads a script apparently doesn't get marked as isProbablySystemOrAddonCode, whereas under the current system it correctly receives the JSVERSION_LATEST handling specific to browser code.

Problem 3.) could probably eventually be properly fixed, but because there's a risk that I might miss some places through which add-on code gets loaded it's somewhat risky. Hence I've omitted everything relating to that and kept support for versioned JS code instead for the time being. While this does mean that some subsequent patches need to be slightly adapted (like e.g. part of bug 1342012 later on), thankfully it was mainly just a matter of continue passing the version parameter through and nothing too difficult to adapt.

The final part of this is the backporting of nullish coalescing, again based on the official Seamonkey backports, which unlike the initial backport by @buc-me have kept the original individual Mozilla commits mostly intact.

Once again the note that because the various backports have been committed in roughly, but not always strictly, chronological order, unfortunately Github (with the exception of the Insights -> Network display) will display in them in some possibly confusing order.

[Peacock365]

@buttercookie42

Thanks for all the work you do, it is great that someone thinks about the usability aspects of WF Classic and not just security patches. It is a bit frustrating to me that Pale Moon's UXP base is getting web compat improvements all the time yet WF Classic gets nothing, perhaps the SeaMonkey backports will help this a bit.

I have another request: It seems like the PDF.js module of WF Classic is getting outdated. Someone has updated PDF.js for SeaMonkey: https://github.com/IsaacSchemm/pdf.js-seamonkey It's not the newest version of PDF.js but it is better than what we have now. Would it be possible to update the PDF.js module, @buttercookie42?

[MrAlex94]

Thanks for the commit @buttercookie42 - just going through it and will pull soon.

[buttercookie42]

No problem, I realise it's quite a big pile of commits. The following parts will be a bit smaller (although some of them not all that much, I guess).