GitHub is broken because of using ECMAScript2020/2021 features

[AroKol78]

many things don't work (sending pictures, ...)

[dirkf]

Fair cop.

What it appears to be doing is replacing any attempt by a GH page to load a script named environment-....js with a specific version that I guess is known good (known not bad?).

You could take your pick as to whether to reproduce this logic in your userscript, or just apply the "polyfill" that I posted above:

• known good solution: won't break if some new horror appears in the served environment-....js, might break if the known good version becomes incompatible with other site JS;
• polyfill: fixes Promise.any() for GH and any other site, including future GH scripts that would only have failed for that reason; might break if some new horror appears in the served environment-....js.

[SeaHOH]

The polyfill Promise.any works well with current GH js.

[rofl0r]

as far as automitcally fixing any such issues in the future is concerned : https://babel.dev/docs/en/babel-standalone

babel features a standalone js (weighing at 2MB minified, 4MB readable) which appears to be quite straight-forward to use. it looks as if an astute browser plugin hacker could turn this easily into a a separate addon that automatically rewrites all incoming js.

[SeaHOH]

Babel transform/rewrite is too heavy, the full javascripts are much bigger.

[JustOff]

Well, here is github-wc-polyfill-1.2.11b1.xpi which implements Promise.any polyfill instead of replacing environment-*.js.

[rofl0r]

Babel transform/rewrite is too heavy, the full javascripts are much bigger.

too heavy for whom? megabyte-big scripts are the norm, not the exception these days. it would certainly have a performance impact, but the plugin/addon could allow to toggle this on/off on a per-site granularity. so you can at least get misbehaving sites like godbolt or github to work.

[SeaHOH]

Babel transform/rewrite is too heavy, the full javascripts are much bigger.

too heavy for whom? megabyte-big scripts are the norm, not the exception these days. it would certainly have a performance impact, but the plugin/addon could allow to toggle this on/off on a per-site granularity. so you can at least get misbehaving sites like godbolt or github to work.

Time, you need more time to transform all javascripts, and deal many cases how to load them.

[dirkf]

as far as automitcally fixing any such issues in the future is concerned : https://babel.dev/docs/en/babel-standalone babel features a standalone js (weighing at 2MB minified, 4MB readable) which appears to be quite straight-forward to use. it looks as if an astute browser plugin hacker could turn this easily into a a separate addon that automatically rewrites all incoming js.

This would be fine in a server-side deployment, where it would be run each time the site JS is deployed to generate the JS that would be served for that site version, and in fact is what sites like GH do or ought to do, or used to when IE was a thing. I doubt that performance would be acceptable if every script from a site was being processed so some caching tactic would be needed that might vary for each site. Again, perhaps better to use effort "up"grading the browser's JS engine.

[SeaHOH]

This would be fine in a server-side deployment

That is very esay to them, but ...

[rofl0r]

btw, the youtube series mentioned earlier in this thread (starting with https://youtu.be/QTm-fqPzjY8 ) is highly interesting, as the guy is hacking on a firefox-style browser using the same concepts as palemoon (IDL files, cpp implementation) implements a couple of things from the html spec regarding to js DOM elements, and it appears to be relatively simple, mostly copy/pasting the spec from MDN and then just turn each step into a line of code.

[garoto]

guy is hacking on a firefox-style browser [...]

Their browser and related "web" engines are written from scratch, which I imagine can be a perk when you don't have to deal with 25+ years of cargo-cult browser code.

But realistically, no browser (from scratch or not) will ever be "2020s web ready" without at least a couple talented individuals working on it 24/7, while being (very well) paid for the job. It's just too much work.

[JustOff]

I'm still using the old polyfill, and it's working for me right now. I think they reverted whatever change they made that broke things. Sorry, my polyfill got auto-updated. Disregard original comment.

@linuxrocks123 In fact you are right, at the moment GitHub started to serve environment.js which includes Promise.any polyfill, so github-wc-polyfill 1.2.9 also works ;)

[dirkf]

GitHub Support wrote:

We have deployed a change today that should improve functionality on older and unsupported browsers.

[JustOff]

Perhaps I'll take a break until Monday before I release any updates, while both 1.2.9, 1.2.10 and 1.2.11b1 work.

[garoto]

Perhaps might be pertinent to mention to those browsing this issue and unaware, but when github started to break with "legacy browsers" like Palemoon around a ~couple years ago, moonwolf|palewolf|wolfbeast was raising issues with GH all the time, and it happened that they would revert or serve a different js framework based on the UA for a while.

It eventually stopped working alltogether, hence this repo.

[AroKol78]

Thanks to JustOff and everyone else involved in solving the problem. (I will be using/testing 1.2.11b1.)

[AroKol78]

again I checked, don't work: editing comments/previw, buttons Show more activity", profile menu

Error: TypeError: (intermediate value).attachShadow is not a function
Source File: https://github.githubassets.com/assets/chunk-index2-a8e52977.js
Line: 1

[dirkf]

This is a separate issue, possibly an aggravation of an existing one: #44 or possibly #19.