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

Add GitLab #25

Closed hawkeye116477 closed 3 years ago

hawkeye116477 commented 3 years ago

I know that it's named GitHub WC Polyfill, but maybe could be possible to add GitLab also to do that list?

https://gitlab.com/gitlab-org/gitlab/-/issues/333598

THEtomaso commented 3 years ago

Moonchild says that "GitLab seems to just want to, stroke for stroke, copy GitHub": https://forum.palemoon.org/viewtopic.php?f=70&t=27006#p216795 If that's the case, then supporting it in GitHub WC Polyfill certainly makes sense.

AroKol78 commented 3 years ago

my page on gitlab is broken buggitlab0

the switch on the UXP browser helps (i don't know if it solves all problems) dom.webcomponents.enabled

THEtomaso commented 3 years ago

dom.webcomponents.enabled

I wouldn't recommend this for anything besides testing purposes. At this point, enabling Web Components support in UXP will cause a lot more problems than it solves! Moonchild has also pointed this out in his release notes.

JustOff commented 3 years ago

I'm sorry, but currently I don't have enough time to support polyfills for anything but GitHub.

Vangelis66 commented 3 years ago

I first became aware of GitLab's 😠 latest breakage 4 days ago, when I visited vanilla's ematrix releases page: https://gitlab.com/vannilla/ematrix/-/releases#v4.4.8 only to find, in distress, that it was rendered (Pale Moon unstable 29.3.0a1 32-bit/Win7SP1 64-bit) without the content I was after... 😞 After another test (latest Serpent 52.9.0 32-bit/WinVista SP2 32-bit), I made sure it was a UXP related handicap... I am sure it was working OK a month ago...

It appears GitLab are gradually transitioning to their next major release, https://docs.gitlab.com/ee/policy/maintenance.html https://about.gitlab.com/blog/2021/06/04/gitlab-moving-to-14-breaking-changes/ to be fully applied, as announced, on June 22nd (which, IIUC, means the GitLab "Next" test version will become GitLab "Current").

UXP devs are pretty much stagnant at evolving further their WC implementation, #1344 #1361 #1592 #1593 ... so GitLab users are found between a rock and a hard place...

I experimentally toggled dom.webcomponents.enabled (to true) and found GitLab to become somewhat usable in UXP (in fact, my comment(s) in https://gitlab.com/gitlab-org/gitlab/-/issues/333598 was written in St52), but I had to jump many hoops to finish those comments - one has to alternate between write/preview tabs a lot to get them formatted correctly...

And while toggling the WC UXP pref brings back some GL functionality, it breaks GitHub with this extension enabled, so a no go again for people who need to work on both GH and GL... Of course, toggling the WC UXP pref alone won't restore GH, the reason this extension was created in the first place...

The fact GL sort of works with dom.webcomponents.enabled;true means, to me at least, a non-JS-coder, that its reliance on WC framework isn't that much widespread (yet?) as in the case of GH, so perhaps a separate/simpler extension could be created to cater to GL idiosyncrasies, rather than extend github-wc-polyfill's functionality... Or, possibly, a userscript could be written for GL as a simpler approach...

I understand and respect the constraints of this extension's maintainer, to which a huge debt 🥇 is owed already for the bulk of his UXP-targeting offerings, so perhaps the wider UXP community should act on this?

hawkeye116477 commented 3 years ago

that its reliance on WC framework isn't that much widespread (yet?) as in the case of GH

GitHub needs more features than only Web Components (for example PerformanceObserver API, queueMicrotask). However if GitLab testing that, then they always could also require in the future too that.

In case of toggling dom.webcomponents.enabled, it could even render some websites blank, like VirusTotal.

JustOff commented 3 years ago

Well, try github-wc-polyfill-1.2.0b1.xpi.

hawkeye116477 commented 3 years ago

Well, try github-wc-polyfill-1.2.0b1.xpi.

It works good on Basilisk.

dilworks commented 3 years ago

Can confirm that also works on Seamonkey 2.53.7.1

Oh, I can't believe the future we're living in: for those of us looking for sanity on our web browsers, we still have to deal with insanity in the web. Man, to hell with Google and modern webdevs :/

micwoj92 commented 3 years ago

Works on Pale Moon too.

JustOff commented 3 years ago

Ok, thanks for the confirmations.

rofl0r commented 3 years ago

does this work only on gitlab.com, or does it also support self-hosted gitlab instances, like e.g. https://gitlab.isc.org/isc-projects/bind9/-/issues/2779#note_220866 or https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/qemu or https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/899 ?

JustOff commented 3 years ago

does this work only on gitlab.com

Yes, however, the instances you mentioned are not poisoned with WebComponents yet.

Vangelis66 commented 3 years ago

thanks for the confirmations.

👍 ... I can also confirm that, at the time of this writing, the "Next" GitLab iteration works, seemingly, OK with gh-wc-polyfill v1.2.0:

GLN

To enable "Next", visit https://next.gitlab.com/ and switch to "Next" (your selection is saved in a cookie) ...

Latest Serpent 52.9.0 32-bit, userstyle is Dark-GitLab Lite v2.0.0-rc.13, installed via Stylus v1.4.23 😉 ...

l29ah commented 3 years ago

Not sure if related, but searching issues at https://gitlab.freedesktop.org/groups/xorg/-/issues doesn't work.

hawkeye116477 commented 3 years ago

@l29ah Just look at console what says :smile:. It's the same problem.

JustOff commented 3 years ago

1.2.1 should cover this and similar cases.

micwoj92 commented 3 years ago

Some organizations use different name, for example https://invent.kde.org :/

JustOff commented 3 years ago

Do you have any other well-known exceptions that are worth adding?

adisib commented 3 years ago

It would be great if https://code.videolan.org could be supported as well.

Vangelis66 commented 3 years ago

... Perhaps you could adopt what the dark-gitlab userstyle does:

https://gitlab.com/vednoc/dark-gitlab/-/blob/master/gitlab.user.css#L24-66

@-moz-document domain('custom.domain'),
domain('invent.kde.org'),
domain('git.pleroma.social'),
domain('gitgud.io'),
domain('salsa.debian.org'),
domain('framagit.org'),
domain('repo.getmonero.org'),
domain('0xacab.org'),
domain('dev.gajim.org'),
domain('devel.trisquel.info'),
domain('git.cit.bcit.ca'),
domain('git.coop'),
domain('git.dev.ctu.univ-fcomte.fr'),
domain('git.drk.sc'),
domain('git.empiresmod.com'),
domain('git.fosscommunity.in'),
domain('git.immc.ucl.ac.be'),
domain('git.jami.net'),
domain('git.linux-kernel.at'),
domain('git.nzoss.org.nz'),
domain('git.silence.dev'),
domain('lab.libreho.st'),
domain('opencode.net'),
domain('skylab.vc.h-brs.de'),
domain('vbscan.fisica.unimib.it'),
domain('git.cardiff.ac.uk'),
domain('git.igwn.org'),
domain('git.ligo.org'),
domain('forge.tedomum.net'),
domain('git.callpipe.com'),
domain('git.happy-dev.fr'),
domain('source.ind.ie'),
domain('mau.dev'),
domain('source.puri.sm'),
domain('git.oeru.org'),
domain('git.najer.info'),
domain('gitplac.si'),
regexp('^https?://(www\.)?git\.(gnu|synz)\.io(/.*)?$'),
regexp('^https?://(www\.)?code\.((videolan|briarproject)\.org|foxkit\.us)(/.*)?$'),
regexp('^https?://(www\.)?source\.(small-tech|joinmastodon)\.org(/.*)?$'),
regexp('^https?://(www\.)?git\.(drupalcode|feneas|ouru|pwmt|regardscitoyens)\.org(/.*)?$'),
regexp('^https?://(www\.)?(joonpc\.skku\.edu/gitlab|mpegx\.int-evry\.fr/software)(/.*)?$'),
regexp('^https?://(web.archive.org/web/.*)?((next|www)\.)?(gitlab\.(?!(io|biterg)).*)(/.*)?$') {

Is it doable in JS? 😄

JustOff commented 3 years ago

Addressed in 1.2.2.

Vangelis66 commented 3 years ago

Many thanks for v1.2.2 👍 , feeling glad my suggestion above did help... 😉