AstroSkipper

The only real issue that all browsers in single-process mode as, for example, New Moon 28, have – and which has always been the case with every version of Firefox – is their inability to free up RAM when tabs are unloaded or closed. The amount of memory that is actually released is pitiful compared to the amount that was originally used. It’s a problem that has remained unresolved since the very beginning, so to speak. And these days, developers no longer worry about wasting RAM, because most of them have plenty of it. But my Windows XP computer doesn't. What is particularly pleasing, however, is that GitHub has been running smoothly in New Moon 28 for some time now and, as far as I can tell, is actually running very well at the moment.

Here's a quick status update on New Moon 28 (32-bit) (2026-06-04) - the current release - under Windows XP running on a single-core 32-bit P4 with 1.5 GB of RAM. I have installed 25 extensions in my profile, 23 of which are enabled, 17 UC.JS scripts, 1 UC.XUL script, 4 USER.JS scripts, and 4 CSS stylesheets. When I launch the browser, it uses 184 MB of RAM, and it takes only a few seconds to load. My browser console shows no errors when the browser starts. If error messages appear, they are caused by websites. The reason for this is that New Moon 28 runs smoothly out of the box – at least as far as the browser console is concerned, thanks to @roytam1 – and I wrote my UC.JS scripts on the premise of running completely error-free. And regarding extensions I either fixed faulty ones myself or, if unfixable, I removed them.

It's good to hear you're doing well. Have you managed to sort out the GitHub issue?

Ok. Thanks!

This is the closed, archived repository of the original uBlock Origin Legacy: https://github.com/gorhill/uBlock-for-firefox-legacy There, you can clearly see that there are no recent patches or updates for it. No more development. @UCyborg started to port patches from the webextension to the legacy version https://github.com/UCyborg/uBlock-for-firefox-legacy. But with long delays in development. His last version is nearly one year ago. And as I already reported, I noticed incompatibilities and higher resource usage when using his version. So, as long as my version is running without any issues, I won’t be making any changes or updates. And if I do, it will only be to the assets, i.e. the filter lists if there are issues. Be that as it may, @Monroe, @Amigafever and @Rod Steel, I'm still pleased to see that there is interest in my uBlick Origin Legacy build.

My main focus was on fixing all the obvious errors caused by a completely outdated XPI file and its incompatibility with the new format of the assets file. That is why I also changed the uBO ID in my version and created my own assets file. As I already said, it’s not easy to implement patches, and that also includes security patches, in legacy extensions that were actually developed for webextensions. So, if you are more interested in security patches of uBO itself, you should use @UCyborg's version and wait for the most recent ones if they are ever implemented. But if you are rather interested in compatibilty and better performance, you should use my version. So it’s entirely up to you.

Everything I reported earlier is already old news. The error has been back in full force for almost a week now. Views are no longer being counted at all. For example:

The @AstroSkipper version is still working. I created it back when nobody was maintaining the legacy version of uBO anymore. This had led to @UCyborg also working on an updated version again. I tested it for a while and actually think any further development is a good thing, but unfortunately I found incompatibilities and higher resource usage. That’s why I’ve gone back to my version. In my opinion, it’s not easy to implement features in legacy extensions that were actually developed for webextensions.

Yes, I used eTools.ch for a while too. But it produced the same rubbish as Google, as it seems to be using Google’s data. I’ve deleted it from my list of search engines.

I’m sorry to hear that, of course. I can well understand how you feel. To put it mildly, I’m not doing too well myself, personally and privately. Especially when it comes to health. I know exactly what you mean. I’m a one-man band in everything I do, too. To be honest, your personal life comes first. So the decision is entirely up to you. Thanks, but I'll decide that for myself. Have a nice night, too!

Since the administrator @xper apparently does not feel it necessary to officially thank his members for their active participation in providing data that led to a precise theory, on the basis of which it was possible to prove the infection of the MSFN server, I shall do so here. @EliraFriesnan, @roytam1, @NotHereToPlayGames, @Ben Markson, @modnar, @deomsh and @nicolaasjan. Thank you for your confirmations with search engine results you generated from all over the world! That was a real community effort at its very best. And since my ‘cloaking’ theory https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/5/#findComment-1287780, which, although based on many facts, remains a theory until it has been subjected to rigorous, unequivocal and, above all, empirical verification, I would like to once again express my sincere thanks to @nicolaasjan for his clever experiment and for highlighting the malware infestation in this post: https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/5/#findComment-1287787. This made the culprit clearly visible and made it impossible to continue ignoring or denying an infection of the MSFN server. In mathematics, this signifies the end of a proof, i.e. q.e.d. And that is the most important thing for me. Cleaning it up was then just a formality and, really, a piece of cake for someone with experience, if you already know exactly what you’re looking for and have been given all the necessary information. Unfortunately, it will now take many weeks for MSFN to recover in the Google index. Not to mention the disastrous drop in the rankings of all MSFN threads.

I don't mind a typo. I don't think @VistaLover owns a time machine either :

I don’t need to stroke my ego. I don’t need to do that, as I know exactly what I’m capable of. But it was simply a reminder of all the hard work I’ve put in since 21 May – work for which any expert would be paid, but which I’ve, of course, offered to the forum free of charge. Your comment is therefore inappropriate and unnecessary.

eagyspider webshell? I think you meant EasySpider webshell, didn't you? As I have never heard or read anything about eagyspider. EasySpider Malware: Type: Backdoor / SEO Spam Injector Infection class: Cross-Site Contamination (as it has been carried over from WordPress to the forum) Mechanism: Dynamic Cloaking & User-Agent Sniffing In any case, a form of "Cloaking" as I predicted here in this thread last Saturday https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/3/#findComment-1287744 and finally last Sunday https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/5/#findComment-1287780 So, good to see that you've found it. And that you have already started to delete some of these thousands of fake or sniffer accounts I mentioned here: https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/8/#findComment-1287893 In any case, I'm glad this thread has served its purpose and that everything turned out well.

Works in Mypal 78, but not in New Moon 28 and Serpent 52. The reason lies in this poorly written function performDownload (line 26, column 119) within the download.js script on the sooftware.com server: function performDownload(num) { event.preventDefault(); ... Strictly speaking, of course, the variable `event` (line 26, column 140) is not defined that way. But Mypal 78 and Supermium seem to be able to handle it. The function performDownload should actually have been constructed this way: function performDownload(event,num) { event.preventDefault(); ... New Moon 28 and Serpent 52 are very sensitive to things like that.