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 :/
They used both named capture groups
and optional chaining operator
:
What the good students are they?
Fail to load right side bar in page (May caused by my network). And hight CPU usage rate.diffs
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:
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?
- File a new, separate, issue, like I did in #58 (GH broke, albeit temporarily...)
- 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!" 😄
- File a new, separate, issue, like I did in #58 (GH broke, albeit temporarily...)
This is better.
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.17https://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... 😉
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)
See previous comments in this thread: 1, 2, 3; IOW:
- Contact the admins of
gitlab.freedesktop.org
and request they update the GitLab software version used in their GL instance 😉 , or - For the purposes of using
gitlab.freedesktop.org
, deploy a different browser profile, withgh-wc-polyfill-v1.2.16
installed (instead of latestv1.2.18.1
); make sure you disable extension auto-updates on that profile, so thatv1.2.16
doesn't auto-update to the latest one (which is no-good forgitlab.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:
github-wc-polyfill/bootstrap.js
Line 352 in 1414868
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.