Browser periodically freezes and unfreezes

[Sessh]

Windows 7 using v33.9.0.

Since the update, I've noticed behavior that did not occur in the previous version. When I load the browser up initially, it runs fine and snappy as it always has. As soon as I open a tweet on x.com, the browser then starts intermittently freezing for about 3 seconds, then unfreezing. Happens when typing, scrolling through tabs, scrolling up and down a webpage and so on. I was able to reproduce this effect in a clean profile as well. Unsure what's causing this, but it absolutely did not happen in the previous version.

Other things I noticed:
If I hop back and forth through my browser tabs with the task manager up, the CPU usage goes up to 13% when it happens, then once it falls, the freeze goes away. If I stop doing anything at all, CPU usage does not spike to 13% and stays around 3%-5% as usual. If I close the browser and restart it, it's fine and snappy until I open a tweet again. Sorry for the lack of details.

Any ideas what this could be? Being that it also happened in a clean profile, I assume this isn't me or an addon.

[Moonchild]

It is unfortunately something with Xwitter's scripting that seriously leaks and causes problems with the JS garbage collector due to object bloating. As a result it is notorious for both causing hangs in the UI as the JS engine tries very hard to clean up the mess but is unable to properly do so, and it can cause closed Xwitter tabs to also remain behind as "ghost" windows that can only be cleared by restarting the browser. While we have done work on trying to forcefully clean up after such sites (through our "ghostbuster", among other things) it doesn't always work, and this site is a major example.
Mainstream browsers will have much less of an issue with this because they just toss out web content processes entirely when you close a tab, and their UI will also be running in a different process than the misbehaving web content, masking the problem (it'll be bad there too but you as a user simply won't see it nearly as much).
I can only suggest you keep your Xwitter use isolated in a different browser like Chromium, Edge, or Brave. This might actually also be beneficial for your privacy as it won't be able to as easily track you if you don't have an active Xwitter login in Pale Moon.

[Sessh]

Unfortunately, you need to be signed in to read anything beyond the original tweet which is the only reason I have an account.

I remember hearing about this sort of thing before, but why didn't this happen in versions before this recent one? I did notice that going to Xwitter would cause the ram usage to creep up, but it never caused hangs after the window was closed like this. Something had to have changed?

[Moonchild]

it may have been exacerbated by the issue addressed in 33.9.0.1. Try updating and seeing if that helps.

[Sessh]

Just updated. Unfortunately no change.

I suppose I will just have to restart the browser every time I look at X for anything until (if) this gets sorted, but I do know this is a new issue that started with the recent update. I would have brought it up before now otherwise because it's quite annoying.

[Michaell]

This may not be the same (I never go to X), but I'm seeing slow/stalling, glitchy, jerky performance even here on this site. I don't know that I can do much if anything to troubleshoot it so reporting may be pointless. Updating to 9.1 did fix the weather service radar.
This probably explains it better than I can (can't get a graph of just PM usage):

cpu.jpg

[Sessh]

Sounds like what I'm seeing here too. Maybe it's not just X causing the issue.
However, I'm not pegging to anywhere near 100%. I've not seen it spike past 13%, but the spike occurs when the jerky performance occurs. It does not happen at all until I open an X window even after I close it.

[Gemmaugr]

Unfortunately, you need to be signed in to read anything beyond the original tweet which is the only reason I have an account.

You don't really. I don't have an account, but read twitter posts (mainly comics) every day through https://github.com/zedeus/nitter/wiki/Instances

[Moonchild]

This may not be the same (I never go to X), but I'm seeing slow/stalling, glitchy, jerky performance even here on this site.

The issue triggered by Xwitter (and similar sites) will put the browser in an unrecoverable state of trying to "sweep the floor" but not being able to, and retrying again and again. Once it is in that state it will affect your browser operation for all sites until the browser is restarted. There is no straightforward solution for this other than a browser restart when it occurs to clear out the trapped memory state. You can use about:memory (-> Measure) to see which URL(s) are the culprit as they will continue to be listed even long after you've closed the site (and may or may not be marked as "ghost"). This might help you to know the problematic site(s) you visit so you can avoid the problem by using a different browser that can handle this kind of mess better than Pale Moon.
Of course if you are on older or less powerful hardware, this will be much more evident, but it does affect the entire range depending on the triggering site visited (and in some cases how long you stay on said site).

[AndieM]

It does not happen at all until I open an X window even after I close it.

Maybe using a 2nd PM-profile could be an option for you. - Start Pale Moon with the parameters `-P --no-remote` gives you the possibility to run multiple instances in parallel. (As long as every instance uses a different profile. Opening a profile multiple times will fail.)

Then you could open Twitter in this instance and the freezing etc. will only occur in this instance. - And you can close it without the need to reopen all other opened websites.

But this option also has caveats. E.g.: Opening links in the wrong Instance by accident (using different themes/ colors can help); separate: history, cookies, settings, add-ons & -updates, etc.pp.

So it could be an option, but if it is depends on your personal usage and requirements.

[Sessh]

You don't really. I don't have an account, but read twitter posts (mainly comics) every day through https://github.com/zedeus/nitter/wiki/Instances

Ah interesting, I thought nitter stopped working and the devs gave up on it. I used to use it before making an account on X. I guess they found a way to make it work with the new way X does things.

There is no straightforward solution for this other than a browser restart when it occurs to clear out the trapped memory state. You can use about:memory (-> Measure) to see which URL(s) are the culprit as they will continue to be listed even long after you've closed the site (and may or may not be marked as "ghost").

I guess my confusion is that this issue only started happening with 33.9.0 and never happened in previous versions, so wouldn't that mean something in 33.9.0 changed that is allowing this to occur? I can deal with the RAM usage creeping up, that's not a major issue.
Re memory, I guess the user can't manually release the memory without a restart?

Maybe using a 2nd PM-profile could be an option for you. - Start Pale Moon with the parameters `-P --no-remote` gives you the possibility to run multiple instances in parallel. (As long as every instance uses a different profile. Opening a profile multiple times will fail.)

Thanks, I'll consider this method as well. Most X links I open are via Discord, but unfortunately, the desktop app does not allow you to choose the browser you want Discord to open links in or I'd just make it use something else.

[Moonchild]

I guess my confusion is that this issue only started happening with 33.9.0

My experience is that it is and has been a persistent problem. 33.9.0 doesn't actually change much at all in the JS engine (just one thing) so there shouldn't be an issue in any major way that wasn't already there.

I guess the user can't manually release the memory without a restart?

The thing is, memory management in a performant way is complex. If there was a way for a user to release memory to resolve the issue, then there would also be a way for the browser to do it without interaction. But there's a lot of complex caching, script compilation, event handlers, listeners, etc. involved in dealing with an obscenely complex JS standard. Garbage Collection can only go so far.

[RealityRipple]

You can technically hit the four "free memory" buttons in about:memoy, which will probably have less and less effect as you go from left to right, with GC being the most useful, but the same processes run automatically when it's been programmatically determined ideal to do a cleanup. But it is a way of manually forcing the action.

[Michaell]

The performance was better this morning. Then I logged into Truth Social (where there are lots of glitches anyway). When I tried to reply to a post there, the browser stalled even more than usual. And the same CPU spikes (and graphics jitters) are back. As far as I can tell, memory isn't the critical issue; it's CPU usage spiking.

[Moonchild]

As far as I can tell, memory isn't the critical issue; it's CPU usage spiking.

The CPU usage is due to the garbage collector trying to clear (scripting) memory that should be free-able but is so tied into a knot that tracing the mess fails (at least that has been my analysis of this issue). GC is pretty intense of a process - this is also explained in the wikipedia article I linked.
the spikes and long pauses are there because the GC runs, goes over the whole mess, can't actually clean anything and gives up. then the cycle repeats the next automatic checking interval.

[UCyborg]

Was stuff from visiting GitHub being able to be cleaned up before? My hunch is that it did behave better not long ago in that case, at least after closing the problematic tabs.

[Enobarbous]

Honestly, it might not just be JavaScript and GC. If there is CSS animation on problematic websites that previously did not work due to the lack of support for revert/@layer/@supports, it may now be putting a strain on the processor.
I am more concerned about the part

If I hop back and forth through my browser tabs with the task manager up, the CPU usage goes up to 13% when it happens, then once it falls, the freeze goes away. If I stop doing anything at all, CPU usage does not spike to 13% and stays around 3%-5% as usual

In the original post. This doesn't seem like GC work, it's more like a problem with observers...

It would be nice if those who experience load surges could show a memory report in this state.

[Michaell]

I'm not an expert on this, but my opinion is this is not a memory issue in the sense of using too much memory. It is some sort of code execution pegging the CPU. I am still seeing spikes after restarting PM with just this forum's active topics open. But these are narrow pointy spikes that don't noticeably affect browsing, unlike the wider at the top spikes that are seen when the browser acts up. I'll leave it there.

[Moonchild]

I am still seeing spikes after restarting PM with just this forum's active topics open.

That, by defintion, means part of the problem you're seeing is not within the scope of Pale Moon. Try doing a full shutdown and restart of your system and see if that gets rid of the spikes you're still seeing? If so, it may be some kind of interaction of the browser (and more specifically its runtime environment/runtime libraries supplied by Microsoft) and Windows 7 throwing parts of the OS in a tizzy. If that's the case then we may have to consider splitting off builds for Win 7 specifically to be built against an older Windows SDK than the one currently used (which is a Windows 11 SDK). That's not really something I'm happy about if so.

[Michaell]

I shut it down overnight and spikes (the pointy ones that don't affect performance) are still there. I close PM and spikes go away, almost dead flat but a few little blips as would be expected.

I had to capture the image before the spikes scrolled off but the flat continued on.

cpu-pm-close.jpg

Here's one from yesterday showing the same thing, first wide spike is logging out of a forum, 2nd wide one ic losing PM. those are expected. But this shows better how flat it stays after that.

cpu2.jpg