All Activity

Well, it was a matter of the purest optimism to have posed the query in the first place.... Perhaps @roytam1 could implement the pref and use it to temporarily shut off :has() support, in the hope that an upstream fix will soon be available.

No...

Does UXP's new :has() support honor that same about:config pref? If so, disabling the pref might be a workaround for the serious performance issues with it.

.css files are all over the place at github. Instead of one very large .css, they seem to use dozens upon dozens of smaller .css files. I only opened three of them and all three used the :has() declaration. While I am not proclaiming the newly-implemented :has() is the root of all of these issues. BUT... it is the ONLY change implemented in the most recent weekly update. So one really doesn't need to have to dig too deep into the change log to see just "what" is causing recent issues.

... But the :has() CSS pseudo selector has been enabled by default since Fx-121 (release channel), while earlier implementations were behind a disabled about:config pref since Fx-103: https://caniuse.com/css-has Firefox is now at version 153.0.4; surely, one can't really blame website owners if the web frameworks they employ make use of :has() ? Even FxESR-115 (supported until March 2027) used on Win7/8/8.1 has the support easily accessible behind the "layout.css.has-selector.enabled" flag; as we've discussed multiple times in the past in these threads, the UXP platform remains oblivious to (practically) all of modern web designers, as backwards-compatibility isn't "a thing" anymore since many years already ; Mozilla use Stylo (or whatever it's called now) for Firefox's CSS features and this is unavailable to UXP devs, so I kind of feel for them ; hopefully, their first attempt at supporting :has() can be made a lot better (if indeed that's the major problem plaguing now GitHub pages, which I'm mostly concerned about ) ...

I realize I'm just an old fart now, but I still don't think it's crazy for me to stick to my ancient 2023 ways, and watch only one video at a time. That said, I suppose it's reasonable for someone to want to "keep an eye on" a live (not prerecorded) video or two other than the one they're actually watching. An example might be watching the local sports team play, while keeping an eye on rival teams' games. At least as long as you can back up and replay the last several seconds if something interesting happens. I even suppose it's possible that some folks are trying to do that sort of thing with their Web browser on an older OS like Windows XP. However, I suspect that's quite rare nowadays.

It's because that page uses a ton of ":has()" .css declarations. This is the very first roytam release that even knows what ":has()" even is. Just one example from loading that page == https://www.comparethemarket.com/assets/Layout.wkRwGAqn.css Note that there are NINE :has() declarations in that one .css file. That page also pulls from a CDN == https://cdn2.comparethemarket.com/experience/web/assets/webui/2.0.0/css/everything.css There are ONE HUNDRED THIRTY FIVE :has() declarations in that one .css file. I can screencap these if you want me to.

Is this the same thing? With Serpent v52.9.0 (2026-08-13) (32-bit) go to https://www.comparethemarket.com – no need to even allow javascript – and simply circle the cursor over the page. Page doesn't even need focus. The CPU goes nuts. Going back to Serpent v52.9.0 (2026-07-31) (32-bit) fixes the problem. Ben.

The basic and in my opinion enough is to disable the automatic defragmentation and of course not to do it manually. Trim is supposed to be unnecessary for the modern SSDs.

I can actually browse GitHub in New Moon 32-bit (latest), but during page load CPU goes to 100% for a while and when that has settled down, clicking on something makes it go to 100% again... Scrolling reacts very slow. (XP SP3 VM; 3.5GB RAM; 1 core assigned)

so the problem may be in :has css support code: https://repo.palemoon.org/MoonchildProductions/UXP/issues/3165

@Dietmar Success for me too! https://ibb.co/yF15pPPr Thanks very much! Can you apply the same fixes you did to the 5449 driver too? (5449 is the last intel graphics driver released for XP as far as I know) https://buzzheavier.com/9ktobfemwe7o edit: Also, can you figure out why AGP texture acceleration is not available in direct X? I think it should be available?

As always, my single-core 32-bit P4 is the perfect tool for diagnosing errors, performance issues and so on. In New Moon 28 32-bit 20260815, any GitHub page causes the entire browser to freeze when it is the active tab. You can’t click on anything anywhere in the interface. A total fiasco.

FFmpeg update. XP: static shared libfdk-aac VISTAx86: static shared libfdk-aac

I think it will be enough to disable the Prefetcher, system file defragmentation at startup, and hibernation. And run Trim periodically — O&O Defrag can do that.

Doesn't Yahoo Mail basic/free have a no-ad-blocker-allowed policy now? I remember getting some message a while back, probably like this

OS: WinVista SP2 32-bit CPU: Intel Core2 Duo T5250 @1.50GHz (2008 era) I also tested the palemoon-28.10.7a1.win32-git-20260815-d849524bd-uxp-e5e0e958e3-xpmod package, actual buildID=20260813020130 Single release GH webpages like https://github.com/violentmonkey/violentmonkey/releases/tag/v2.47.1 open relatively easily/quickly and the page is responsive and scrollable; the relative timestamps and asset toggle previous issues appear fixed; trying to load the full list of Releases page, https://github.com/violentmonkey/violentmonkey/releases is not as smooth/quick; while the page loads, one CPU core is constantly busy, but after the page has been fully rendered, the CPU used by process palemoon.exe soon drops to 0-1%; the page is scrollable, but the scroll itself is NOT smooth... But when absolute disaster strikes is when one tries to access and load the Issues List view of a GH repository, say https://github.com/violentmonkey/violentmonkey/issues During page load, one CPU core hangs at 100%, the second ranging from 40-55% ; overall CPU consumption by process palemoon.exe fluctuating between 49-60% ; after the page has been rendered, the CPU does settle down to 1-2%, but the page is extremely laggy and unresponsive; it can hardly be scrolled down/up with the native browser scrollbar, PGUP/PGDN keys sometimes work after several seconds have passed, while any attempt to scroll the page skyrockets the CPU to 45-60% ... As I very often visit issue trackers of various GH repos to view open/closed tickets and often create new ones myself or comment on existing ones, having an unresponsive Issues List page is a deal-breaker for me ... PS: I don't have gfx-accel (OMTC) enabled, as my driver is old and blacklisted; scrolling the Issues List View pages gets somewhat better (but not by much) by manually enabling Asynchronous Pan/Zoom (APZ) in about:config (apz.desktop.enabled to true and restarting NM) ...

UPDATE: I just discovered, by chance while researching something else, that Dell had apparently released an updated Windows 7 ISO back in 2016 for select models with Skylake processors (including the OptiPlex 7050), which, naturally, includes the updated NVMe and USB 3.0 drivers, along with any updates released up to then (of which there are many). I don't know how to get it from Dell directly, but I found a copy of the 7050-specific ISO on the Internet Archive, which I'm downloading now. I see no reason why this ISO won't work, so it appears that this is the solution I was hoping for! c

It's a Dell OEM ISO, so it has a few updates (SP1 and such). Yes, but apparently that's not enough? c

Are you trying to install Windows 7 RTM or with some updates? Have you added the necessary NVMe hotfixes KB2990941 & KB3087873 along your NVMe drivers?

The latest update is online...sorry, forgot to post the last... : The mirror of latest ArcticFox 44, BNavigator 0.9, Firefox 28/45ESR, IceApe 52, IceDove 52, K-Meleon 1.5.x/74/76, MailNews 52, New Moon 26.5/27/28, RetroZilla, RZ browser and Serpent 52/55 builds by @roytam1 has been updated -> soggi.org - tools. changelog: - added latest BNavigator 0.9 20260815 build - added latest IceApe 52 20260815 build - added latest IceDove 52 20260815 build - added latest MailNews 52 20260815 build - added latest New Moon 28 20260815 builds - added latest Serpent 52 20260815 builds - added latest Serpent 55 20260815 builds To don't lose track of things I want to update too someday... todo: - add various flash player versions - add FlashFix for WinXP - add VLC 2.2.8 (WinXP non-SSE2) done! - add polyfill addons Kind regards soggi

Yessssssaaaaaaaaaaa!!!!!!!!!!! Dietmar https://www.upload.ee/files/19651199/igxpmp32_5445_CF53_DEV_0A16_PPS5_NULLGUARD3_TEST.sys.html I get 15781 points in 3DMark2001 Panasonic Toughbook CF-53 Mk4 – Intel HD 4400 DEV_0A16 under Windows XP SP3 I finally have the Intel 5445 XP graphics driver running on my Panasonic Toughbook CF-53 Mk4 with the Haswell-U Intel HD 4400 (PCI\VEN_8086&DEV_0A16). This was debugged live with WinDbg over KDNET. The original Intel 5445 driver installs normally, but after reboot it crashes exactly like the system tested by @Damnation. Hardware / software Panasonic Toughbook CF-53 Mk4 Intel Core i5-4310U Intel HD Graphics 4400 PCI Device ID: 8086:0A16 Windows XP SP3 32-bit Intel XP graphics driver 6.14.10.5445 Kernel debugging via WinDbg/KDNET The unmodified 5445 driver installed without any problem. On the first reboot, however, XP produced: PAGE_FAULT_IN_NONPAGED_AREA BugCheck 50 Arg1: F000EEF3 Arg2: 00000000 Arg3: F000EEF3 Arg4: 00000002 WinDbg initially reported: Probably caused by : igxpmp32.sys The stack clearly went through igxpmp32.sys. The interesting detail was that both the referenced address and instruction address were: F000EEF3 1. Finding the real cause of BSOD 0x50 Initially I suspected a bad Haswell-ULT MMIO access. We traced one suspicious Intel register read of offset: 0x64440 The live call was: Context = 8A50F350 MMIO base = B8BFE000 B8BFE000 + 64440 = B8C62440 Immediately before the read: ESI = B8C62440 EDI = B9B265A8 ECX = 00000001 The actual Windows function was: nt!READ_REGISTER_BUFFER_ULONG and the read completed successfully. The returned value was simply: 00000000 So the 0x64440 MMIO access was not the source of the 0x50. The important discovery came later. In igxpmp32 we reached: igxpmp32+171850: mov eax,[igxpmp32+26601C] push eax mov ecx,[igxpmp32+26601C] call dword ptr [ecx+90h] The global object pointer was: [igxpmp32+26601C] = 00000000 Therefore: ECX = 00000000 Immediately before the crash we confirmed live: call dword ptr [ecx+90h] with: ECX = 00000000 Then: dd ecx+90 L1 00000090 f000eef3 This explains the original BSOD completely. The Intel driver was effectively doing: ECX = NULL CALL DWORD PTR [NULL + 0x90] [00000090] = F000EEF3 CPU executes CALL F000EEF3 => PAGE_FAULT_IN_NONPAGED_AREA 0x50 So F000EEF3 was not a mysterious GPU MMIO address. It came directly from low memory at address 0x90. We first tested the workaround manually by skipping the call and forcing: AL = 0 The function returned cleanly. We then replaced the six-byte call in RAM: Original: FF 91 90 00 00 00 call dword ptr [ecx+90h] Temporary patch: 33 C0 90 90 90 90 xor eax,eax nop nop nop nop This eliminated the original BSOD 0x50. 2. After fixing 0x50: BSOD 0xEA With the first fix applied, the driver progressed considerably further, but Windows then hit: THREAD_STUCK_IN_DEVICE_DRIVER BugCheck EA The new stack led us into: igxpmp32+175871 The driver was polling register: 0xC7200 The loop was: mov edx,[ebp-4] shr edx,1Ch and edx,3 cmp edx,1 je retry mov eax,[ebp-4] shr eax,1Fh and eax,1 je retry The value returned for C7200 was: 00000000 so the loop could never terminate. The interesting part was the Intel internal register-descriptor table. It contained 21 entries. The last five registers were: 61200 61204 61208 6120C 61210 There was no C7200 entry. The complete five-register sequence was therefore: 61200 61204 61208 6120C 61210 while the Haswell/PCH panel-power code was requesting: C7200 C7204 C7208 C720C C7210 This looked extremely suspicious. The internal read routine searched its table for the requested register. If no matching entry existed, it simply returned FALSE and left the supplied DWORD unchanged at zero. Therefore the sequence was: request C7200 | v C7200 not present in internal table | v read routine returns FALSE | v output remains 00000000 | v polling code waits forever | v 0xEA watchdog 3. First PPS test: 61200 -> C7200 We changed the first table entry temporarily in RAM: 61200 -> C7200 Immediately afterward the exact same read returned: C7200 = 80000008 instead of zero. This was a major confirmation. The polling conditions were now satisfied: Bit 31 = 1 Bits 29:28 = 00 The driver exited the first polling loop. So the register-table mismatch was real. 4. Complete panel-power register patch The driver later accesses the complete PPS register set, so we changed all five table keys: 61200 -> C7200 61204 -> C7204 61208 -> C7208 6120C -> C720C 61210 -> C7210 Together with the original NULL-call patch, XP now progressed far enough that I could see the Windows XP desktop for approximately one second. That was the first time the Intel 5445 driver actually reached visible accelerated graphics initialization on this Panasonic. However, another problem appeared afterward. 5. Third bug: another NULL object dereference After progressing beyond the PPS problem we caught a second-chance exception: Access violation - code C0000005 igxpmp32+16F1AF: cmp edx,dword ptr [ecx+68h] WinDbg showed: Attempt to read from address 00000068 and: ECX = 00000000 So this was another straightforward NULL-pointer dereference. The relevant routine searches several objects. The normal object list contained four entries. Their field +68h values were: 00000006 00000007 00000008 00000005 The requested value was: FFFFFFFF Therefore there was correctly no match in the normal list. The function then uses an optional fallback object: movzx edx,byte ptr [object+54h] test edx,edx je no_fallback mov ecx,[object+58h] mov edx,[ebp+0Ch] cmp edx,[ecx+68h] The live object contained: [object+54h] = 00000001 [object+58h] = 00000000 In other words: fallback-present flag = TRUE fallback pointer = NULL The driver therefore executed: cmp edx,[NULL+68h] and crashed. The correct behavior if the fallback does not exist is simply to return NULL, because that is exactly what the function already does when the fallback does not match. So a NULL guard was added: fallback = object->fallback; if (fallback == NULL) return NULL; if (fallback->field68 != requested) return NULL; return fallback; 6. Final patch set The currently working experimental 5445 driver therefore contains three fixes. Fix 1 – initial 0x50 Prevent: call dword ptr [NULL+90h] at the path around: igxpmp32+171867 The failed call is replaced by a FALSE return: xor eax,eax nop nop nop nop Fix 2 – Haswell/PCH panel-power register mapping Internal PPS table: 61200 -> C7200 61204 -> C7204 61208 -> C7208 6120C -> C720C 61210 -> C7210 Fix 3 – missing fallback NULL check Around: igxpmp32+16F1A9 the fallback object obtained from [object+58h] must be checked against NULL before dereferencing [fallback+68h]. Result With these three modifications the behavior changed from: install Intel 5445 reboot immediate BSOD 0x50 / F000EEF3 to a system that progresses through the Intel HD 4400 initialization and reaches the Windows XP desktop. Most importantly, the original mysterious: F000EEF3 has now been completely explained. It comes from: NULL object -> [NULL+90h] -> DWORD at physical/low virtual address 00000090 -> F000EEF3 -> CALL F000EEF3 -> BSOD 0x50 The subsequent 0xEA also had a concrete explanation: the 5445 driver was looking for the Haswell panel-power register C7200, while the selected internal descriptor table contained the older/different 61200 PPS register set. Finally, once those problems were bypassed, another missing object initialization became visible and required a simple NULL guard. So the important conclusion is: DEV_0A16 itself is not fundamentally incompatible with the XP 5445 driver. The driver already contains a large amount of the required Haswell support, but on this Panasonic/Haswell-U path several initialization assumptions are wrong: an object used by the +171850 path is NULL, the wrong PPS register descriptor set is selected, another optional fallback object is marked present although its pointer is NULL.

@Dietmar Yep, this is the same BSOD at the same memory address as my Toughbook. Are you confident that you can find the cause of this BSOD?