JustOff/github-wc-polyfill

Argh... GitLab is broken again (regex/named capture groups)

dilworks opened this issue · 46 comments

Today must be a horrible day for everybody using source hosting sites which are hellbent on making life miserable to anyone not using Chrome®™ or a Chrome®™-compatible browser. Now GitLab is breaking again because they decided it was a good idea to deploy named capture groups on their regexes for no good reason at all.

Apparently the polyfills injected by the addon cause GitLab to load one of their scripts... which breaks because it now contains unsupported regexes. The error console logs this:

SyntaxError: invalid regexp group commons-pages.admin.topics.edit-pages.admin.topics.new-pages.groups.epics.new-pages.groups.epics.sho-59a8e774.9fc6fd37.chunk.js:1:285
	onStopRequest jar:file:///home/tomman/.mozilla/seamonkey/7b88ug1a.default/extensions/github-wc-polyfill@Off.JustOff.xpi!/bootstrap.js:430:7

Since SeaMonkey doesn't support named capture groups (yet), the entire tower of cards falls down there, and GitLab goes back to its usual behavior for anyone not using A Blessed Browser™ (i.e. everything broken, can't read anything but the first post on a issue, etc.)

When will the madness stop!? Maybe it's time to declare JavaScript and Google war criminals against mankind at the United Nations :/

What the good students are they?

Here is a dirty error bypass hack: 1.2.13b3.

Fail to load right side bar in page diffs (May caused by my network). And hight CPU usage rate.

Fail to load right side bar in page diffs.

An example URL. plz.

Fail to load right side bar in page diffs. And hight CPU usage rate.

I checked some GitLab addresses and it works fine on ST52

Fail to load right side bar in page diffs.

An example URL. plz.

I restart my browser, and it work. May caused by my network.

Haha I knew GL being the second worst won't stay out of this browser war for long! And their timing strongly suggests M$ insidership.

But that's enough. Where would you guys suggest I should move my projects? Codeberg?

Once again, thank you very much, @JustOff !!!

Another small victory in this endless cat-and-very-shiny-mouse chase. Can confirm that Gitlab works again on SeaMonkey.

Ironically, when you open the console there, you get a welcoming message to "make GitLab more lovable" (complete with emojis, ON A CONSOLE). Sure, right, "lovable". As long as you love Chrome®™, of course!

in https://foss.heptapod.net/seamonkey/mozilla-release it shows this error:

21:41:30.912 SyntaxError: invalid identity escape in regular expression 1 main.fb387d50.chunk.js:50:117850
	onStopRequest jar:file:///G:/palemoon/profile/extensions/github-wc-polyfill@Off.JustOff.xpi!/bootstrap.js:476:7

on ST52

Timestamp: 2022-03-13 15:12:42
Error: SyntaxError: invalid identity escape in regular expression
Source File: https://foss.heptapod.net/assets/webpack/main.fb387d50.chunk.js
Line: 50, Column: 117850
Source Code:
slice(r);return i&&n.push(i),n},i=t=>{if(t){const e=t.match(/^\p{Emoji}/u);return e?e[0]:t.charAt(0).toUpperCase()}retur

github-wc-polyfill-1.2.17b1
The main GL was droped escape emoji in regular expression, but some instances may not be.

The main GL was droped escape emoji in regular expression

😡 ; "main" GitLab is again BROKEN here (202203170045 UTC), due to them using unsupported (in UXP) regex syntax... 👎 😠

Latest St52+gh-wc-pf-1.2.16/1.2.17b1,
sample GL URL:
https://gitlab.com/seamonkey-project/seamonkey-2.53-mozilla/-/commit/1a9bb8dcae068ea13ddbabcb5620f4e5ab0ea1f8
Result:

GL

Error Console log:

Timestamp: 17/03/2022 02:57:00
Error: SyntaxError: invalid regexp group
Source File: https://gitlab.com/assets/webpack/commons-pages.admin.topics.edit-pages.admin.topics.new-pages.groups.epics.new-pages.groups.epics.sho-59a8e774.e7c29e61.chunk.js
Line: 1, Column: 285
Source Code:
,i=n.n(o),r=n("79X9"),s=n("oj/M");const a="[{text}](url)",l=/^(?<indent>\s*)(?<leader>((?<isUl>[*+-])|(?<isOl>\d+\.))( \

... Seems there's no end to this ordeal 😭 ; one day is GH, the next GL, and so on... 😞

Seems like the newly released Pale Moon 30.x throws an error when trying to install the extension, likely a simple versioning issue?

Seems like the newly released Pale Moon 30.x throws an error when trying to install the extension, likely a simple versioning issue?

Works with Moon Tester Tools, so that must be it

Both the beta github-wc-polyfill-1.2.17b2 and latest release github-wc-polyfill-1.2.17 mitigate the GitLab breakage I reported, so many thanks for the speedy fix! 🥇
And I've been meaning to ask:
SeaHOH, since you're the current active maintainer of this extension, what should the best course of action be the next time either GH/GL break?

  1. File a new, separate, issue, like I did in #58 (GH broke, albeit temporarily...)
  2. Post a comment in a previously existing closed issue, like I did this time (GL broke, I posted #45#issuecomment-1069796890 ) ?

Thanks a lot! 😄

the newly released Pale Moon 30.x throws an error
when trying to install the extension,
likely a simple versioning issue?

Works with Moon Tester Tools, so that must be it

As if having to constantly deal with GitHub/GitLab breaking this extension every other day or two 😠 wasn't enough, now MCP, reshuffling the deck of cards, are tossing more obstacles in the way of this extension 😞 ...

https://www.palemoon.org/releasenotes.shtml

Pale Moon is abandoning its own GUID (globally-unique identifier) and adopting Firefox's GUID instead

So, this won't simply be "a versioning issue", as PM30 now has internally the same GUID as Fx30/Fx52 etc., Basilisk 52.9.2022.01.27 and Serpent 52.9.0 ... Meaning that this code block

      <Description>
      <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id>
      <em:minVersion>28.14.0</em:minVersion>
      <em:maxVersion>29.*</em:maxVersion>
      </Description>

inside install.rdf will no longer be relevant for PM >= 30.0.x (but remains so for PM 28.14 - 29.4.4 and, with modification, for New Moon 28); instead, PM30 must be accommodated, somehow (?), inside the Basilisk code block below:

      <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>52.9.2020.10.05</em:minVersion>
        <em:maxVersion>52.9.2022.*</em:maxVersion>
      </Description>

E.g., setting a minVersion of 30.0.0 will allow for installation in PM30 (but also allows installation in Firefox 30.0-52.9.0 , should one attempt that) ...

Later EDIT: It has since emerged that PM 30.0.x does still allow the installation of PM GUID targeting extensions, so that the Basilisk (Fx) GUID block need not be modified, yet... Read this 😉 ...

In addition, our platform code has been changed to a more streamlined version over the past months and UXP is no longer used (or maintained) by us in this milestone. UXP has been released to the community for maintenance and coordination to continue building on where desired. Instead, we are now building on the Goanna Runtime Environment™ (or GRE for short)

The (new) GRE platform (revamped UXP, tailored for PM30+) means that future PM versions will diverge significantly over time from UXP browsers, what will the future bring to them (NM28/Basilisk/Serpent) as far as this crucial extension is concerned? Continued or dropped support?

Most notable user-facing/implementation changes:

  • Implemented queueMicroTask() for web compatibility.

Currently this extension polyfills that for ALL supported platforms/applications, PM30 should probably be exempt from that, as natively supported (?) ...

For add-on developers:

  • Pale Moon now internally identifies with the Firefox GUID.
  • blahblahblah...

So, do everyone now see how the waters have been mudded?

cutting out support for unmaintainable components and target platforms

I'd hate it if extension support (unofficial as it might be 😉 ) is lost for Serpent 52, and I'm not the only one using it around here (and in dire need of this superb extension) ...

Oliver Hardy addressing Stan Laurel: "Well, here's another nice mess you've gotten me into!" 😄

  1. File a new, separate, issue, like I did in #58 (GH broke, albeit temporarily...)

This is better.

l29ah commented

gitlab doesn't work for me even with the latest update
https://gitlab.freedesktop.org/mesa/mesa/-/issues/6145 is empty

@l29ah The site app is outdated, you should ask the manager to update, or use old add-on.

on ST52 + 1.2.17
I don't know if it matters, but on the given page I have it

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6145 is empty

Timestamp: 2022-03-19 18:46:17
Error: SyntaxError: invalid regexp group
Source File: https://gitlab.freedesktop.org/assets/webpack/commons-pages.admin.topics.edit-pages.admin.topics.new-pages.groups.milestones.edit-pages.groups.mil-2c3731d7.227b1daa.chunk.js
Line: 1, Column: 285
Source Code:
,r=n.n(o),i=n("79X9"),s=n("oj/M");const a="[{text}](url)",l=/^(?<indent>\s*)(?<leader>((?<isOl>[*+-])|(?<isUl>\d+\.))( \

  • https://gitlab.freedesktop.org/mesa/mesa/-/issues/6145
    ok 1.2.16
    bad 1.2.17
  • https://gitlab.com/seamonkey-project/seamonkey-2.53-mozilla/-/commit/1a9bb8dcae068ea13ddbabcb5620f4e5ab0ea1f8
    bad 1.2.16
    ok 1.2.17

😕

Great - so I updated to PM 30.0 - only to find the Polyfill fix is no longer compatible so I cannot work with GitHub in PM. Looked to see whether a downgrade to 29.x would be worth a shot - only to be warned on the PM website that I would risk "poisoning/tainting" my profile permanently for any PM version by doing that - and then finding that it is impossible to retrieve older recent version because after leaving, Tobin has taken that archive and the forums downs: https://www.reddit.com/r/palemoon/comments/ti1okk/ntpmat_hes_done_finally/ . At the moment I am on Windows so I guess I will be forced to use Chromedge unless/until this f***up gets sorted...

😠

Hell, I had to do that just to edit a typo in this comment.

Edit: For what it is worth the IP address of forums.palemoon.org seemed to be 31.7.187.157 but it isn't clear that there is anything left there now...

updated to PM 30.0 - only to find the Polyfill fix is no longer compatible

install.rdf modify sub <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id> to the appropriate versions

<em:minVersion>52.9.2020.10.05</em:minVersion>
<em:maxVersion>52.9.2022.*</em:maxVersion>

change to

<em:minVersion>28.14.0</em:minVersion>
<em:maxVersion>30.*</em:maxVersion>

(I have not tested on PM30)

@AroKol78 👍 Superficially that seems to be working... I can see Emojis, the drop down "..." menus seem to work and I can edit posts.

so I updated to PM 30.0 - only to find the Polyfill fix is no longer compatible so I cannot work with GitHub in PM

Hi 😄 ; your comment is best suited for #59 (PM30 related), this one is tracking GitLab breakages... 😜

Looked to see whether a downgrade to 29.x would be worth a shot -
only to be warned on the PM website that I would risk
"poisoning/tainting" my profile permanently

This is indeed true; always backup fully the current browser profile prior to updating to any major new release (29.4.4 => 30.0.0); if things "break" for you, you'd have a working previous profile to fallback to...
If a 29-profile is touched by PM30, it becomes to an extent (difficult to tell beforehand) incompatible/corrupted with PM29, as profile upgrades are only one-way (the same is true for other browsers, e.g. Chromium-based or Mozilla Firefox, etc.).

and then finding that it is impossible to retrieve older recent version

If it's 29.4.4 you're after, try these links:

https://rm-us.palemoon.org/release/palemoon-29.4.4.win32.installer.exe
https://rm-us.palemoon.org/release/palemoon-29.4.4.win64.installer.exe
https://rm-us.palemoon.org/release/palemoon-29.4.4.win32.7z
https://rm-us.palemoon.org/release/palemoon-29.4.4.win64.7z
https://rm-us.palemoon.org/release/Palemoon-Portable-29.4.4.win32.exe
https://rm-us.palemoon.org/release/Palemoon-Portable-29.4.4.win64.exe

May quit working anytime soon... 😉

@SlySven Please comment to the corresponding issue. #59

it happens again:

Error: SyntaxError: invalid regexp group

Source File: https://gitlab.com/assets/webpack/commons-pages.admin.topics.edit-pages.admin.topics.new-pages.groups.epics.new-pages.groups.epics.sho-59a8e774.e3a8a1a8.chunk.js

Line: 1, Column: 1627

which is: l=/^(?<indent>\s*)(?<leader>((?<isUl>[*+-])|(?<isOl>\d+\.))( \[([xX ])\])?\s)(?<content>.)?/,c=/^((\s{0,3}-+\s*-+\s*-+\s*[\s-]*)|(\s{0,3}\*+\s*\*+\s*\*+\s*[\s*]*))$/;

... Can also confirm (04/04/2022, ca. 16:50 UTC) 😞 ; gh-wc-pf-v1.2.17, Serpent v52.9.0 (2022-03-25) (32-bit), Error Console output follows for my GL test page:

Timestamp: 04/04/2022 19:51:23
Error: SyntaxError: invalid regexp group
Source File: https://gitlab.com/assets/webpack/commons-pages.admin.topics.edit-pages.admin.topics.new-pages.groups.epics.new-pages.groups.epics.sho-59a8e774.e3a8a1a8.chunk.js
Line: 1, Column: 1627
Source Code:
,o=n.n(r),i=n("79X9"),s=n("oj/M");const a="[{text}](url)",l=/^(?<indent>\s*)(?<leader>((?<isUl>[*+-])|(?<isOl>\d+\.))( \

FWIW, after my recent exchange with this extension's current maintainer, perhaps it would be better to open a new issue for this latest GL breakage 😉 ; though, to be fair, this issue has remained in an Open status ever since originally filed on Feb 18th...

v1.2.18b1 tested in St52 and found to successfully address this latest breakage! 👍

I don't want to sound ominous, but GitLab are announcing currently the release of their next major milestone, v15.0, scheduled for May 22nd; I expect (but hope against) several additional breakages till that date... 😞

Still getting this after update

02:31:30.022 SyntaxError: invalid regexp group 1 commons-pages.admin.topics.edit-pages.admin.topics.new-pages.groups.milestones.edit-pages.groups.mil-2c3731d7.9d206744.chunk.js:1:285

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10525 (any MR)

@mittorn

See previous comments in this thread: 1, 2, 3; IOW:

  1. Contact the admins of gitlab.freedesktop.org and request they update the GitLab software version used in their GL instance 😉 , or
  2. For the purposes of using gitlab.freedesktop.org, deploy a different browser profile, with gh-wc-polyfill-v1.2.16 installed (instead of latest v1.2.18.1); make sure you disable extension auto-updates on that profile, so that v1.2.16 doesn't auto-update to the latest one (which is no-good for gitlab.freedesktop.org).

Yep, just wait an update by them. Or take a rollback of addon.

Yep, just wait an update by them. Or take a rollback of addon.

that seems impractical tbh. maybe there's a way (checksum of script) to detect which fix needs to be rolled out ?

that seems impractical tbh. maybe there's a way (checksum of script) to detect which fix needs to be rolled out ?

It is a pity that this is not applicable to our framework of the addon.

maybe there's a way (checksum of script) to detect which fix needs to be rolled out ?

Theoretically, this should still be possible, but I'm not a coder myself;
IINM, the gitlab.freedesktop.org self-hosted GL instance is picked-up by the extension according to:

const glmask = "^gitlab\\.|^((0xacab|framagit)\\.org|code\\.(briarproject\\.org|foxkit\\.us|videolan\\.org)|dev\\.gajim\\.org|forge\\.tedomum\\.net|foss\\.heptapod\\.net|git\\.(alchemyviewer\\.org|callpipe\\.com|cardiff\\.ac\\.uk|cit\\.bcit\\.ca|coop|drk\\.sc|drupalcode\\.org|empiresmod\\.com|feneas\\.org|fosscommunity\\.in|gnu\\.io|happy-dev\\.fr|immc\\.ucl\\.ac\\.be|jami\\.net|ligo\\.org|linux-kernel\\.at|najer\\.info|nzoss\\.org\\.nz|oeru\\.org|pleroma\\.social|pwmt\\.org|rockylinux\\.org|silence\\.dev|synz\\.io)|gitgud\\.io|gitplac\\.si|invent\\.kde\\.org|lab\\.libreho\\.st|mau\\.dev|mpeg\\.expert|opencode\\.net|repo\\.getmonero\\.org|salsa\\.debian\\.org|skylab\\.vc\\.h-brs\\.de|source\\.(joinmastodon\\.org|puri\\.sm|small-tech\\.org))$";

and is then "treated" (unsuccessfully 😞) with whatever GL-targeting code exists in latest v1.12.18.1;
what if an "exclusion rule" is added to that detection logic just for gitlab.freedesktop.org and then feed that GL-instance the (working) code extant in v1.12.16 ?
Is that within the realm of feasibility?
Of course, it would be an ugly (interim) kludge, susceptible to breakage whenever "freedesktop.org" eventually update their underlying GL-instance code...

Of course, it would be an ugly (interim) kludge, susceptible to breakage whenever "freedesktop.org" eventually update their underlying GL-instance code...

indeed, it would be much nicer to detect that it needs the old fix by checksumming (or checking filesize) of the js script in question.

btw it seems salsa.debian.org also uses an older version of gitlab.

btw it seems salsa.debian.org also uses an older version of gitlab.

It's Debian, what do you expect :^)

btw it seems salsa.debian.org also uses an older version of gitlab.

Confirmed 😞 (like in the case of gitlab.freedesktop.org, mostly individual merge_requests URIs seem to be affected, e.g.

https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/292 )

github-wc-polyfill-1.2.18.2.xpi
This release includes all the patches for "invalid regexp group".

github-wc-polyfill-1.2.18.2.xpi
This release includes all the patches for "invalid regexp group".

that's great! i'm a bit amazed that i can't find a corresponding commit in the commit history. i'm curious how you implemented it.

i can't find a corresponding commit in the commit history.

It will be commited later. And now, view it in xpi package.

please increase the version number in update.xml (1.2.18.1 and 29)

please increase the version number in update.xml

Yep, it in the plan, but isn't pressing.