Leaderboard

upstream tested and it needs to be reverted. https://forum.palemoon.org/viewtopic.php?p=272957#p272957

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!

but it is still can be overloading CPU as threadCount = cpuCount+4: https://github.com/roytam1/UXP/blob/69d0209956c29ea5ec21eaaa6414773389445d6d/js/src/vm/HelperThreads.cpp#L77 BTW I wonder if LoongArch changes can be imported to moebius repo without big changes. EDIT: decided not to merge LoongArch changes.

... Not reverted per se in the end , but modified to cater for old single or double core CPUs : https://repo.palemoon.org/MoonchildProductions/UXP/issues/3066 https://repo.palemoon.org/MoonchildProductions/UXP/commit/3259bdc1c14deea4c4ec3133901b783ea37d5c09

I was thinking if it is caused by https://github.com/roytam1/UXP/commit/ae7c40d4611542893882b2a3ea5d739852962734

next build will change parse-thread count from core-count*4 to core-count - 1 to see if this helps. if not, it will further reduce back to single parse-thread later.