Substack_Comments Won't Load

[larryg]

https://rwmalonemd.substack.com/p/lawsu ... wp-company

There's a link to load additional comments at the end of the article,
( scroll to article end, after the cartoon ) and click on :

"285 more comments… "

Doesn't work in PM (it used to, not sure when it stopped), OK in other browsers.

Thank you,



Timestamp: 8/24/2022 9:03:08 AM
Error: SyntaxError: invalid identity escape in regular expression
Source File: https://substackcdn.com/min/main.bundle ... 82ccb60468
Line: 50, Column: 165378
Source Code:
.trim().replace(/\s+/g,"-").replace(/&/g,"-and-").replace(n?/[^\p{L}-]+/gu:/[^\w-]+/g,"").replace(/-+/g,"-");return t&&t
[/code]

[Moonchild]

It's because of \p{L}
The whole "unicode categories in regex" is an obscenely complex to implement standard, especially if (like us and mozilla for that matter) you don't have the devs in house to slot it into an already complex regex engine. See https://www.regular-expressions.info/un ... l#category
Read though that. If there's a way someone can help with it, it'd be appreciated. A practical solution like using a lookup table to replace {L} and other unicode groups with something our current parser understands would be fine, too.
Otherwise, when writing regex, especially if just using it for trimming, please use normal (unicode) ranges which are fully supported, instead of shorthand like this.

[Weasel]

Doesn't look so complicated to me. It has a lot of categories, yes, but they should all be in a table somewhere, no? In the spec or something.

And since unicode ranges are supported, in theory just map each category to a sequence of ranges. It shouldn't even need a lot of code, just a std::map which maps the category name to an array of ranges (with length since there can be variable number of ranges). I don't know anything about Mozilla code though, but that's how I'd code it personally, but well, maybe the browser's regex engine (from Mozilla) isn't sane and requires some refactoring.

I mean yeah it's going to take some time to make all the tables, but for me "complex" means something that requires a hard solution, not just something tedious. This is the latter, imo.

[athenian200]

And since unicode ranges are supported, in theory just map each category to a sequence of ranges. It shouldn't even need a lot of code, just a std::map which maps the category name to an array of ranges (with length since there can be variable number of ranges). I don't know anything about Mozilla code though, but that's how I'd code it personally, but well, maybe the browser's regex engine (from Mozilla) isn't sane and requires some refactoring.

I mean yeah it's going to take some time to make all the tables, but for me "complex" means something that requires a hard solution, not just something tedious. This is the latter, imo.

Well, the main problem is that the regex engine we have is a half-busted ancient version of Google's Irregexp that Mozilla imported and jerry-rigged to work with their codebase. Any attempt we make to modify it to add the functionality we need results in weird stack corruption issues. The way they implemented it in the first place depended on it not doing certain things with memory, and the new functionality unfortunately does a lot of those things. Mozilla did later import a newer version of irregexp, but what they did hasn't helped us because their JS engine had changed too much by the time they did it.

https://repo.palemoon.org/MoonchildProd ... ssues/1279

https://repo.palemoon.org/MoonchildProd ... ssues/1362

Basically, every time we try to improve the regex engine we have, something breaks and we wind up having to roll it back. The easiest solution is probably to import a newer irregexp somehow, but that task has been... well... yeah. It just seems like this is an issue that no matter how we approach it, there doesn't seem to be a solution.

[Weasel]

Yuck, that does sound horrible, I guess I shouldn't be surprised it's a spaghetti mess. Thanks for the clarification.

[Moonchild]

Honestly, at this rate I'm more tempted to actually look and see if we can go back to what Mozilla had initially for regex: a self-hosted JS module implementing regex parsing and processing in javascript. It would be a ton easier to maintain and extend than this glueing in of foreign Google code (literally the "standard" here is just a description of "what irregex implements" because Mozilla is literally using Chrome code for it -- this is why I call them "Google regex extensions")

[unknownone]

I've experienced the same issue and it affects all buttons (including the one to subscribe an author, to visualize all comments, the "Let me read it first", the like and comment buttons, etc..) on the substack webpage and all subdomains that host the articles of all authors that publish there.

I've took my time to file a support ticket to ask them to provide a fall-back code for non-mainstream browsers, using their form https://support.substack.com/hc/en-us/requests/new. I hope they will consider and apply a fix on their side (basically reintroducing the previous button code as alternative code).

[unknownone]

I've received a reply from Substack's support, informing me that my bug report and suggestion will be forwarded to the Product team for discussion.