Leaderboard

So, in the end, I was right with my early findings about the CPU usage even Moonchild had to confirm I just really hope that those thread parsing corrections help to make NewMoon/Goanna engine smoother, on CPU I mean. The actual smooth would be accomplished on the javascript engine (as Firefox 115), someday... ------- FOLLOWS, AFTER ALL OFF-TOPIC ----- Sorry if I haven't replied these days, I've been testing RAM (that you know it takes loooooooot of time) with thunderstorms in the middle that didn't allow me to even plug the PC and now I'm fixing problems on a family member PC. And the RAM and processor are fine. In the meantime I rechecked all my previous debuglogs (made with debug wizard help) and, even the "probably caused by: win32k.sys" is very... (as any other with microsoft) imprecise, and I never considered it to be the real problem, I searched and applied the latest(?) win32k.sys update named KB3095649 which, in theory, might help, but as told, I haven't had time to test yet, because I was able to reproduce intentionally the BSOD, so I guess I could test. Answering to other mentions, the disk is not the problem as, long ago, decided to run the profile on a ramdisk (made with ImDisk) thanks to the decision long ago form Mozilla, and so MoonChild, and so Gecko and Goanna engine, to use an sqlite database for the history. You can't believe the performance hit that is managing those databases on disk, really. It is a continous read/write. And Firefox, using localStorage on sqlite databases for browser cache... you couldn't believe the performance difference of running it on a ramdisk. Anyway, I'm digressing right? I will test if NewMoon now crashes the system (not because of NewMoon but because I found a good testing vector), but that is something on my side. EDIT 2026-05-01T03:30+2: for what I tested before go to sleep, I couldn't reproduce the BSOD, so, fingers crossed, let's hope I don't have new BSODs with NewMoon as vector for win32k.sys BSOD, nor any other program. Or maybe today wasn't the same environment and didn't crash. The upcoming days will tell. And I hope the newer NewMoon builds, without the Goanna engine CPU hog, would be helpful as well.

Technically, I would use the word "idle" instead of "freeze". Idle = intentional pause, WILL resume when tab becomes active... Freeze = unintentional hang, will NOT resume when tab becomes active...

Chromium/Forks will *only* have that option on MOBILE DEVICES such as laptops. It will appear on chrome://settings/performance BETWEEN the Memory and Speed options, but again *only* on mobile devices. Desktop: Laptop:

alright, that rev is reverted.

Thanks for identifying this ; so, a backport from "dactyloidae" ; well, as we all know, NM28 doesn't support WE at all, so, IMHO, it should've been excluded from this change, though I realise that the change is platform-wide, not app-specific... In any case, that commit (that upstream won't ever merge, as they don't support WE at all) was probably NOT accurately authored, because it disables the standard installation of a category (with strictCompatibility=true) of non-WE (i.e. XUL/legacy) addons that the platform itself (UXP) should support natively/out-of-the-box; in addition, have you actually bestowed upon Serpent 52 WE-support on par with fx-128? I am but a casual UXP user by now , but this looks like a true regression to me ... What are your feelings about this? Are you inclined to fix or revert that commit? Or should one manually modify the XPIs of ALL addons with strictCompatibility=true to have them installed/re-enabled in UXP apps after the 20260418 updates? Thanks for your precious time!