Page 5 of 6

Re: PM 28.14.2 Github

Posted: 2020-11-06, 17:59
by own3mall
Microsoft sucks. I'm sick of their BS when it comes to just about everything these days.

Recently, they blocked one of my server's IP ranges from sending email to any Microsoft email address. I contacted them asking why my range had been blacklisted and if there was a way it could be removed from the blacklist. They responded with no information and said that range cannot be removed from their blacklist ever. So, I had to work-around their crap following this guide (https://www.linuxbabe.com/mail-server/m ... -blacklist). My server is not on any other blacklist, and it does NOT send any spam whatsoever. It's so frustrating that you can't get anywhere with Microsoft, and that they don't even want to talk to you about anything.

Same case here with GitHub and PM. We need to boycott all MS products (email, GitHub, and anything else they've ruined like Windows 10).

Such a sad state of the world today. I'm not really motivated to do much of anything anymore. Development used to be fun. Now, it's mainly about fixing problems that shouldn't have been a problem in the first place. :cry:

I noticed their file upload control isn't working in PM on GitHub today, so I'm affected by this too. I may have to start moving everything to my GitLab instances :(

Re: PM 28.14.2 Github

Posted: 2020-11-06, 18:58
by New Tobin Paradigm
Same. But Gitlab is just as bad.. Because it is a big name GitHub competitor AND really the same bs technology pushed by Google and Microsoft are being used on Gitlab as is the same mindset and objectives in basic frontend and backend development of Gitlab. Three times I can recall recently they have busted stuff and eventually they will stop fixing it for anything but Chrome.

Re: PM 28.14.2 Github

Posted: 2020-11-06, 19:39
by Moonchild
own3mall wrote:
2020-11-06, 17:59
I noticed their file upload control isn't working in PM on GitHub today, so I'm affected by this too. I may have to start moving everything to my GitLab instances :(
Please reconsider before you waste your time on moving to GitLab. They are hard on their way to become just as Chromium exclusive as GitHub with the exact same mentality that Google WebComponents are a "must have". If you migrate to them you get to migrate again later on because they will stop providing working code for anything but the monopole.

Re: PM 28.14.2 Github

Posted: 2020-11-07, 02:58
by adesh
own3mall wrote:
2020-11-06, 17:59
Such a sad state of the world today. I'm not really motivated to do much of anything anymore. Development used to be fun. Now, it's mainly about fixing problems that shouldn't have been a problem in the first place. :cry:
Off-topic:
So true. I feel like this EVERYDAY! Lots of hurdles to get something done. Motivation has gone for me too.

Re: PM 28.14.2 Github

Posted: 2020-11-14, 13:23
by Kudalufi
I just noticed a whole bunch of automation is broken on github for PM and ran into this thread. It seems to work properly in FF, so it's not just Chrome it works with. What is causing this?

Re: PM 28.14.2 Github

Posted: 2020-11-14, 13:44
by Moonchild
Kudalufi wrote:
2020-11-14, 13:23
I just noticed a whole bunch of automation is broken on github for PM and ran into this thread. It seems to work properly in FF, so it's not just Chrome it works with. What is causing this?
I believe that is already answered a few times over in this very thread.

Re: PM 28.14.2 Github

Posted: 2020-11-16, 06:34
by Kudalufi
Moonchild wrote:
2020-11-14, 13:44
Kudalufi wrote:
2020-11-14, 13:23
I just noticed a whole bunch of automation is broken on github for PM and ran into this thread. It seems to work properly in FF, so it's not just Chrome it works with. What is causing this?
I believe that is already answered a few times over in this very thread.
So sorry, I didn't see it was a 5 page thread so only caught the tail end of the conversation.

Thank-you to JustOff for the extension. Sadly, I don't agree that it is the right answer.
Moonchild wrote:
2020-11-03, 12:54
Well they made clear they have no interest in being browser-agnostic. You can be glad it still works at all.
The difficult conversation that needs to happen is what does "browser agnostic" even mean in this context? Does it mean "works with every browser"? Does github work with Lynx? Does it work with the PlayStation browser? Or does browser agnostic mean it works with most>

The reality is that, however much we as users all love PaleMoon, and no matter how merit-based your development decisions have been, it is not PM nor its users or developers that get to decide what is the base level of support a browser needs to have. We also don't get to decide what toolkits become defacto standards for web sites that make up major internet infrastructure. We don't get to do that any more than Lynx users and developers get to. PaleMoon is somewhere in the .15% of unknown browsers in marketshare. Github's answer, as arrogant as it may be, we have to look at it from their PoV.

However frustrating it is that the big players are making decisions that are not merit-driven, the fact is they are making these decisions and we don't have a user base that is large enough to make a dent in that process. We don't. We just don't. Not if we all write to them. We only get to vote with our feet. The difficult choice you personally have to make for PM is between bending to assholes or irrelevance for PM. I don't envy that. The one we have to make is between holding in there with a browser that we love and want to be able to use, and the reality that increasingly we have to rely on "backup" browsers for more and more sites. Unfortunately, my hope right now is that you bend to the assholes, because I really don't want to have to move on from a piece of software that, for so long, has had my back.

Re: PM 28.14.2 Github

Posted: 2020-11-16, 10:24
by Moonchild
With "browser agnostic" I mean using a reasonable level of feature support, and not pushing "bleeding edge" tech on a development platform that does see an extremely wide usership of people on all sorts of operating systems and environments. I'm well-aware it is their decision ultimately what browsers they support and we have no say in it. It is also no coincidence that this browser support became a problem without a solution when Microsoft (a browser vendor themselves who do benefit from having more users on it) became owner and started to make web UI changes to cater to Chredge that none of the developers using the forge asked for in any way, and many disliked. Previously as stated several times before there was always a reasonable dialogue with GitHub staff and even though there was no "official" support, if there was a reported problem it was still solved for our use. No more of that, now. I don't even get an answer any more to reported issues.

So if you want to reason from the browser marketshare percentage point of view then yes we have no reason to exist as we do in the eyes of decisionmaking for large websites that want quantity over quality, and we may as well fold. But what does that percentage mean in raw numbers? Roughly a million people/active installs - actually a multi-year stable figure. That's not nothing.
Also, it has always been a webmaster's task (by definition) to cater the website to reasonable levels of accessibility of their content consumers. If not, they will lose their business. And lo and behold, with us moving to Gitea in-house, they have lost our development pool (and potential income from services). That is the game here, not some theoretical number-juggling but real patronage.

Re: PM 28.14.2 Github

Posted: 2021-01-05, 10:07
by Tomaso
Here's another uBO rule..
It makes the issue tags at GitHub more readable, when using Pale Moon:

Code: Select all

github.com##div[class*="Label" i]:style(color: black !important;)
(Relevant discussion @ https://github.com/DandelionSprout/adfi ... -753666401)

PS:
To fix GitHub's camoufalged search bar, use the uBO rules which I posted here:
viewtopic.php?f=70&t=25435&start=40#p202117

Re: PM 28.14.2 Github

Posted: 2021-01-07, 07:50
by LigH1L
JustOff wrote:
2020-10-15, 15:25
Here is a workaround: GitHub Web Components Polyfill.
I was told about another extension: Polly is supposed to increase compatibility for several websites, shall even work with multiprocess (e10s, may have to be disabled for the extension above), but may be less stable, according to a note at doom9:
VoodooFX wrote:For Github select:
Use request modification...
Webcomponents-sd
Webcomponents-ce
I already installed JustOff's extension and it works well for github in Pale Moon and in Seamonkey.

Re: PM 28.14.2 Github

Posted: 2021-01-07, 08:36
by coffeebreak
LigH1L wrote:
2021-01-07, 07:50
another extension: Polly
Unfortunately Polly is a WebExtension, and for that reason it's not compatible with Pale Moon and other UXP browsers.

Re: PM 28.14.2 Github

Posted: 2021-01-09, 18:33
by Tomaso
Tomaso wrote:
2021-01-05, 10:07
Here's another uBO rule..
It makes the issue tags at GitHub more readable, when using Pale Moon:

Code: Select all

github.com##div[class*="Label" i]:style(color: black !important;)
A minor adjustment was necessary:

Code: Select all

github.com##[class*="Label" i]:style(color: black !important;)

Re: PM 28.14.2 Github

Posted: 2021-01-09, 18:38
by New Tobin Paradigm
This has gone way past the WebComponents issue.

You guys need to stop or create a new thread elsewhere.

Re: PM 28.14.2 Github

Posted: 2021-01-09, 18:44
by Tomaso
New Tobin Paradigm wrote:
2021-01-09, 18:38
You guys need to stop or create a new thread elsewhere.
OK.
Regarding uBO rules, I'll try to keep this post updated:
https://github.com/DandelionSprout/adfi ... -753672908
Inputs or questions can be posted in the same thread.

Re: PM 28.14.2 Github

Posted: 2021-01-16, 15:19
by UCyborg
I was asked for confirmation code when I logged in to GitHub today, probably because I had user-agent set for that site that omits the Firefox part (the email I received said Unknown Browser on Windows), it fixed display issues in the past, before they dropped browsers without WebComponents entirely.

Seems that override is no longer needed. I normally pretend that I'm Firefox 62.0, it strikes me as a better choice than default 68.0 because actual Firefox 68.0 supports bells and whistles that UXP browsers don't.

Re: PM 28.14.2 Github

Posted: 2021-01-16, 19:40
by Moonchild
UCyborg wrote:
2021-01-16, 15:19
it strikes me as a better choice than default 68.0 because actual Firefox 68.0 supports bells and whistles that UXP browsers don't.
UXP browser also support bells and whistles that Firefox 62.0 don't.
So any choice of compat version is a compromise -- by the way, you can globally set the compat version to something else with a preference as well.

Re: PM 28.14.2 Github

Posted: 2021-01-16, 20:03
by UCyborg
Aye, I figured it might be dependent on what sites you visit.
Moonchild wrote:
2021-01-16, 19:40
by the way, you can globally set the compat version to something else with a preference as well.
Do you have "general.useragent.compatMode.version" in mind? That's the one I had in mind. ;)

Re: PM 28.14.2 Github

Posted: 2021-02-04, 02:48
by SlySven
Sorry to say but I've upgraded to day to 29.0.0 and GitHub has gotten crippled again. I have github-wc-polyfill 1.1.7 but it feels like it is not doing anything. Is this just me or are others encountering this problem again.

Re: PM 28.14.2 Github

Posted: 2021-02-04, 11:03
by Moonchild
I think it's just you. GitHub looks fine with the polyfill on v29 here.

Re: PM 28.14.2 Github

Posted: 2021-02-13, 22:23
by SlySven
As you suspected it was just me... :oops: