JustOff / github-wc-polyfill

Ensure that all GitHub and GitLab scripts required for UXP and SeaMonkey are loaded correctly
https://justoff.github.io
Mozilla Public License 2.0
103 stars 19 forks source link

GitHub is broken because of using ECMAScript2020/2021 features #43

Closed AroKol78 closed 2 years ago

AroKol78 commented 2 years ago

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

firefox_2022-02-11_00-37-22

roytam1 commented 2 years ago

it uses new javascript syntax now

RamonUnch commented 2 years ago

Hopefully there are some workarounds

JustOff commented 2 years ago

There will be no workarounds until the issue isn't described properly, including steps to reproduce and what exactly goes wrong.

AroKol78 commented 2 years ago

I don't know what I need to fix the bugs (last edition Serpent52/UXP) don't work: editing comments, sending pictures, buttons ("Show more activity","Edit profile",...), profile menu, recent activity, ...

JustOff commented 2 years ago

Well, the problem is optional chaining (?.) operator introduced in Firerox 74, see https://bugzil.la/1566143.

rofl0r commented 2 years ago

i wonder if it would be possible to build something like https://github.com/babel/babel into palemoon which automatically transpiles all incoming js to the version it supports before executing it.

garoto commented 2 years ago

Well, the problem is optional chaining (?.) operator introduced in Firerox 74, see https://bugzil.la/1566143.

Is this something "workaroundable" without too much hassle?

rofl0r commented 2 years ago

this is quite a deal breaker. can't even create a release from a tag anymore.

hiiamboris commented 2 years ago

poor bastards just can't stop breaking things

garoto commented 2 years ago

(since I can't edit my post above because "edit" is broken) It's also a nice parallel to the state of Palemoon currently and in general.

ghost commented 2 years ago

@garoto, You can still pick your reaction to GitHub comments with Pale Moon, so not all is bad... yet ;)

garoto commented 2 years ago

Like so after a full page refresh? lol.

I'm starting to think its time for me to "move on", it's all getting really tiresome...

ghost commented 2 years ago

I'm starting to think its time for me to "move on", it's all getting really tiresome...

Yeah, its good time to move from GitHub:

garoto commented 2 years ago

lol, to be honest, everything you listed is "hot garbage".

gitlab? c'mon now... "IF" I was looking for a place to host software, it'd be at sourchut's (https://sr.ht).

garoto commented 2 years ago

But I guess you're only posting this garbage because "omg, microsoft bought github!!1". github is the same garbage webiste now as it was before the mega-software-conglomerate aquisition.

The only difference in 2022 is that now they have 30+ employees more with colored hair while living in the SF streets like hobos.

SeaHOH commented 2 years ago

Change the User-Agent version's number below v74 is a temporary relief:

name: general.useragent.override.github.com
value: Mozilla/5.0 (%OS_SLICE% rv:68.9) Gecko/20100101 Firefox/68.9
dirkf commented 2 years ago

I "reached out" to GH and they reverted the change. I haven't checked whether they're serving optional chaining to their supported browser versions and only reverting for other UAs, which I suggested as an option.

mh3663 commented 2 years ago

I "reached out" to GH and they reverted the change. I haven't checked whether they're serving optional chaining to their supported browser versions and only reverting for other UAs, which I suggested as an option.

As a SeaMonkey enthusiast and lurker on the a.c.s.seamonkey newsgroup, I applaud you. Cheers!

ghost commented 2 years ago

I "reached out" to GH and they reverted the change.

@dirkf, WOW! You emailed them or there is public issue thread on this?

JustOff commented 2 years ago

They reverted the libs for all browsers, so I'm afraid that it's only temporarily and will not last long.

Also, just compare these two lines from their environment.js:

o=(r=(e=t.head)==null?void 0:e.querySelector('meta[name="expected-hostname"]'))==null?void 0:r.content;
e=t.head?.querySelector('meta[name="expected-hostname"]')?.content;

Which approach you think will survive?)

dirkf commented 2 years ago

Also, just compare these two lines from their environment.js:

But that's what they send out, not what's in the source tree? I expect they have some TypeScript or ES2020 "transpiler" in the build process that can be configured as to the output JS level.

The high-level response that I received said that they would review the browser support page, the breaking changes announcement process, and make the site changelog more transparent.

TBH I was astounded and on top of the Youtube-dl takedown response extreme kudos (for now) to GH management.

rofl0r commented 2 years ago

interesting. previous requests like this were ignored by gh management, maybe it's got to do with you being a youtube-dl contributor.

rofl0r commented 2 years ago

ok, that was a short success, now e.g. github actions is broken again: example https://github.com/rofl0r/desmume-gtk2/runs/5144809199?check_suite_focus=true - can't look at the build log anymore

AroKol78 commented 2 years ago

the same problems came back as I wrote earlier

dirkf commented 2 years ago

Deprecation Notice for ECMAScript2020 Support

But they seem to have jumped the gun.

JustOff commented 2 years ago

Well, at the moment GitHub does not work even in Firefox 78 ESR. This means that our chances for a workaround tend to zero.

AroKol78 commented 2 years ago

Deprecation Notice for ECMAScript2020 Support GitHub.com but with limited functionality

can't even handle the basics of things

..."Show more activity","Edit profile",...), profile menu,...

SeaHOH commented 2 years ago

Deprecation Notice for ECMAScript2020 Support

Page not found now, maybe they will revert this too.

AroKol78 commented 2 years ago

now I don't even see any bugs in the console (csp warning exception) and github is still not working properly

JustOff commented 2 years ago

Well, the blog post remained in the cache:

firefox_2022-02-11_00-37-22

linuxrocks123 commented 2 years ago

Maybe you could fix it by intercepting the http requests where they get their JavaScript libraries and replacing them with the old ones from before the change?

Vangelis66 commented 2 years ago

Deprecation Notice for ECMAScript2020 Support

... While these "competent" M$ coders are sorting their English spelling mistakes ("2022-02-10-deperecation-notice-for-ecmascript2020-support/"), they now claim they "haven't written that blog post yet":

deperacation

Edit: SeaWater beat me to it :smile:

Slightly OT :wink: : Users of official UXP browsers/SM/WF-Classic on Win7+ still have the option of using an ECMAScript2020-compliant browser, if only for GitHub; but M$ have dealt the most severe blow to the retrocomputing communities (e.g. XP/Vista users), of which the OP is a member (and partly myself, on my older - but favourite - laptop) ... Chromium [79/]80 was the version where "?." was first implemented, there exist very few (mostly Chinese) forks based on Ch >=79 that can run on XP/Vista; @AroKol78 : I'm now posting this on 360EEv13[Ch86 based], the very LAST 360EE version that will run on XP/Vista x86) - it mostly works, but is heavy on resources, especially on older H/W...

This means that our chances for a workaround tend to zero.

Apologies in advance if what I suggest is infeasible, but can't we do a search-and-replace "job" for "*?." syntaxes, like the one that got us GitLab back in the UXP platform?

SeaHOH commented 2 years ago

Apologies in advance if what I suggest is infeasible, but can't we do a search-and-replace "job" for "*?." syntaxes, like the one that got us GitLab back in the UXP platform?

We can't, babel transform is needed.

And

now I don't even see any bugs in the console (csp warning exception) and github is still not working properly

Vangelis66 commented 2 years ago

but with limited functionality

Sadly, things are more dire in my case... :angry: ; not only does GitHub not work in latest Serpent 52 32-bit (as posted by OP), now when I focus on a GitHub tab, with and without the github-wc-polyfill extension enabled, my CPU (both cores) is heavily taxed, even maxing to 100%:

cpu

Most likely, some endless loop is taking place... As soon as I switch to a non-GH tab, CPU drops to 5-8% ... Thank you Microsoft/GitHub for frying my laptop! :angry:

JustOff commented 2 years ago

Thanks to everyone for your ideas about possible methods of combating new changes, but unfortunately at the moment none of them is suitable. Perhaps the integrated Babel processing could be a solution, but it is too difficult to implement and I'm not sure that it's worth the effort.

ghost commented 2 years ago

Sadly, there is no results in Google WebCache or even Web Archive:

But Twitter in same time still can parse website card:

Twitter screenshot

dirkf commented 2 years ago

Maybe you could fix it by intercepting the http requests where they get their JavaScript libraries and replacing them with the old ones from before the change?

Foolishly I forgot to save them. Did anyone in fact do so? ISTR an extension that would allow you force a site to load its resources from a local cache, not one of @JustOff's though?

dirkf commented 2 years ago

Of course, editing a post is one of the broken functions.

It may well be that it's actually almost as easy/difficult to bastardise the XUL browsers with this feature rather than work-around it for a specific case.

Vangelis66 commented 2 years ago

Sadly, there is no results in Google WebCache or even Web Archive:

http://webcache.googleusercontent.com/search?q=cache%3Ahttps%3A%2F%2Fgithub.blog%2Fchangelog%2F2022-02-10-deperecation-notice-for-ecmascript2020-support%2F

I had no trouble loading the GWC link (different CDN to you?); here's a searchable PDF capture of it:

Deprecation Notice for ECMAScript2020 Support - GitHub Changelog.pdf

dirkf commented 2 years ago

My high-level contact says that the deprecation post was "a mistake" and the browser support policy is still being reviewed.

Today's breakage is weird because the JS still appears to be reverted, no errors in the console, the quoted fragment is the non-chained version, but the original breakage is back, possibly on all unsupported browsers?

Apparently this extension isn't the problem either, although if we diagnosed the current issue properly it might be amenable to fixing with the extension unlike the optional chaining issue itself.

The cockup-theorist in me would like to hypothesise that those in the GH build team whose ambition is to ensure that the site only works with a browser whose major version has 3 digits are not really getting the message.

linuxrocks123 commented 2 years ago

If they unbreak it long enough for someone to download the unbroken JavaScript, I expect it should be possible to modify the extension to use said unbroken JavaScript. It would certainly be worth downloading it just in case. I'll try to download it if it gets unbroken for me again, but fancy web dev isn't really my thing, so I'd suggest not relying on me to do that.

FakelsHub commented 2 years ago

Fucking Microsoft!

dirkf commented 2 years ago

https://support.github.com/ticket/personal/0/1499112

Description

Yesterday a swathe of site functions stopped working for browsers that don't support the optional chaining feature of ES2020.

That change was rolled back, resulting in several hours of good service as before.

Since some time this afternoon (a little before 2022-02-10T17:43:03Z) the site has again started to show a similar set of breakages, although the JS being served does not seem to include optional chaining and there are no errors shown in the browser console. The issue now affects even browsers that do support optional chaining (eg, Firefox 78ESR), but are below the supported version level publicised by GH (whether this latter is significant has not been tested).

This has been observed by numerous users across different GH projects.

Reproduction Steps

Access the site with a browser like Firefox 78ESR, log in. In an issue,

  • use the reaction button on a post -> works
  • try to use the ┅>Edit/Hide/Quote menu -> pop-up appears with circular loading animation, nothing happens.
rofl0r commented 2 years ago

the new breakage without any output in js console is highly suspicious. it's almost as if the JS was tweaked especially to no longer work with palemoon.

ghost commented 2 years ago

@dirkf, If you would get some feedback, please post screens too.

rubyFeedback commented 2 years ago

it's almost as if the JS was tweaked especially to no longer work with palemoon

I think the larger goal is to suppor tonly the chromium code base. I am having problems in firefox as well recently with github.

JustOff commented 2 years ago

Let me repeat, that at the moment even Firefox 78 ESR (which supports most of the ECMAScript2020 features, including the optional chaining operator) does not work properly with GitHub. And while there are no errors in the console, it is not possible to find the cause.

Upd: mozregression points to Promise.any proposal from ECMAScript2021. I, perhaps, refrain from commenting on this.

dirkf commented 2 years ago

So we need this: https://github.com/ungap/promise-any/blob/master/index.js ?

I applied this as a NoScript surrogate for <github.githubassets.com with success (joining a Promise.AllSettled() that may or may not be needed now for app.element.io):

if (!('any' in Promise.prototype))
    Promise.any = function ($) {
        return new Promise(function (D, E, A, L) {
            A = [];
            L = $.map(function ($, i) {
              return Promise.resolve($).then(D, function (O) {
                  return ((A[i] = O), --L) || E({errors: A});
              });
            }).length;
        });
    }

@dirkf, If you would get some feedback, please post screens too.

As a demonstration, see the updated hidden comment, which now quotes the private bug report.

it's almost as if the JS was tweaked especially to no longer work with palemoon

I'm still going with GH devs being very much at home to Mr Cockup.

JustOff commented 2 years ago

I somehow managed to make GitHub work again, at least the main functionality. However, it is unlikely to last long.

As a demonstration, see the updated hidden comment.

That comment is hidden because the ticket is visible only to its author. I made it visible again.

Vangelis66 commented 2 years ago

As a demonstration, see the updated hidden comment.

That comment is hidden because the ticket is visible only to its author.

Yes, you are correct, but @dirkf probably intended to link this hidden/minified comment of his :wink: ...

Your fix was tested to function as intended in latest Serpent 52, congrats! :tada:

Many thanks :smile:

... Related, but probably OT :wink: BTW, can a JS guru among you translate the "fix" in 17b52b6 to a userscript format I could install in Violentmonkey and regain GH usability in a Chromium 78 fork? 'Promise.any()' was only implemented in Chromium 85 :sob: ...