Investigate JS libraries for Polyfills

[The-Compiler]

As evident in #7335 and https://github.com/qutebrowser/qutebrowser/tree/master/qutebrowser/javascript/quirks, we need Polyfills for JS features from time to time, especially for people on older QtWebEngine versions.

Often it's difficult to find minimal standalone polyfills, or they happen to only do a part of the full implementation, without really being standards-compliant.

We should investigate if we could somewhat easily build and ship e.g. core-js, ungap or Polyfill.io in a way where we only get the polyfills we actually need.

[mentalisttraceur]

Opinion: the Righter(tm) place for polyfill responsibility is either

1. the website, if it knows it wants to support older browsers (those coding a website are the ones in the best position to know exactly what is a complete-enough or close-enough polyfill for what that code is doing), and

2. the user, if they know they don't want to upgrade the web engine (the user is in the best position to figure out what polyfills are complete-enough or close-enough for the websites they are using).

It seems like supporting general polyfills in the browser's releases is signing up for the hardest version of this problem: providing polyfills that are complete and close enough for approximately all needs.

I think maybe the right move is to pick a reasonably recent version of QtWebEngine to support at each Qutebrowser release, and only have logic for grabbing polyfills for the features missing from that oldest-supported QtWebEngine version at the time of that release being cut. (Personally I think a reasonable time gap is however far back mainstream browsers support old versions of themselves, or at most whatever the delay is between each Debian Stable release if you want to be really altruistic).

[mentalisttraceur]

There is also a danger with "polyfill blocking" - blocking the right polyfill by providing a less appropriate one.

When writing websites, my normal style for polyfills is to test if the feature already exists, and polyfill it if it doesn't.

So for example, if Symbol doesn't exist, I might add a good-enough-for-me Symbol polyfill.

But if the browser has already preemptively polyfilled it with a "good enough (for '99%' of the use-cases)" polyfill, well, first of all that will cause my check for "do I need to polyfill this?" to fail, but also it might provide a polyfill which doesn't actually work right for my use-case, while possibly still being heavier-weight than my polyfill because it makes sure to polyfill commonly-used features that I don't even need.

[toofar]

Our current JS quirks (which include a couple of very specific pollyfills) are already site-specific and optional (the content.site_specific_quirks.* settings). Although it does look like we could be a bit better about tagging them with specific Qt releases they are needed for.

I think this is just about getting polyfill implementations of specific objects/methods from somewhere else automatically, probably at build time, when we know we already know need them. Otherwise we just copy and paste them currently which is a bit of a pain.

[The-Compiler]

Although it does look like we could be a bit better about tagging them with specific Qt releases they are needed for.

We already do that, FWIW:

https://github.com/qutebrowser/qutebrowser/blob/951a14a66bb39dee089887642ac4c2b6dcb3b612/qutebrowser/browser/webengine/webenginetab.py#L1212-L1223

I think this is just about getting polyfill implementations of specific objects/methods from somewhere else automatically, probably at build time, when we know we already know need them. Otherwise we just copy and paste them currently which is a bit of a emall.

Precisely - and so far, the hand-written quirks tend to be very KISS, but also really only cover a minimum of the functionality. That means they are probable more prone to breakage on site changes than a properly maintained polyfill would be.

[Lanny]

We should investigate if we could somewhat easily build and ship e.g. core-js, ungap or Polyfill.io in a way where we only get the polyfills we actually need.

corejs has a mechanism for bundling together a specific set of polyfills that would probably good a good fit here if there's still a need for polyfills: https://github.com/zloirock/core-js/tree/master/packages/core-js-builder