Closed AroKol78 closed 2 years ago
it uses new javascript syntax now
Hopefully there are some workarounds
There will be no workarounds until the issue isn't described properly, including steps to reproduce and what exactly goes wrong.
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, ...
Well, the problem is optional chaining (?.) operator introduced in Firerox 74, see https://bugzil.la/1566143.
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.
Well, the problem is optional chaining (?.) operator introduced in Firerox 74, see https://bugzil.la/1566143.
Is this something "workaroundable" without too much hassle?
this is quite a deal breaker. can't even create a release from a tag anymore.
poor bastards just can't stop breaking things
(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.
@garoto, You can still pick your reaction to GitHub comments with Pale Moon, so not all is bad... yet ;)
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...
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:
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).
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.
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
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.
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!
I "reached out" to GH and they reverted the change.
@dirkf, WOW! You emailed them or there is public issue thread on this?
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?)
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.
interesting. previous requests like this were ignored by gh management, maybe it's got to do with you being a youtube-dl contributor.
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
the same problems came back as I wrote earlier
Deprecation Notice for ECMAScript2020 Support
But they seem to have jumped the gun.
Well, at the moment GitHub does not work even in Firefox 78 ESR. This means that our chances for a workaround tend to zero.
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,...
Page not found
now, maybe they will revert this too.
now I don't even see any bugs in the console (csp warning exception) and github is still not working properly
Well, the blog post remained in the cache:
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?
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":
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?
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
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%:
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:
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.
Sadly, there is no results in Google WebCache or even Web Archive:
But Twitter in same time still can parse website card:
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?
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.
Sadly, there is no results in Google WebCache or even Web Archive:
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
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.
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.
Fucking Microsoft!
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.
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.
Ticket not found
The ticket either does not exist or you no longer have access to it.
@dirkf, If you would get some feedback, please post screens too.
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.
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.
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.
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.
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:
many things don't work (sending pictures, ...)