Browser tab crashes when many pages have been appended

[grgoffe]

Description

Howdy,

I REALLY LIKE this extension!

I'm seeing random Firefox "gah, site crash" messages Firefox Nightly (FFN) around URL 167 on this NSFW site. INFY-SCROLL always stops working at around URL 167.

This problem has existed since I installed the extension approximately 2 months ago. I'm at the "current" update for this extension AND the FFN I'm using.

I have not posted the Site in question because it's NSFW.

Thanks for the WAY COOL CODE!

URL

NSFW

Version

10

Browser

Firefox Nightly 153.0a1 (2026-06-09) (64-bit)

OS

Linux Fedora Rawhide (current)

Device

Other

Adherence

• I have read the Sticky

[sixcious]

Hi grgoffe, thank you for the kind words and for opening this issue! ❤️

I'm guessing you mean you're trying to append a whole 167 pages in a single tab? There isn't anything written in Infy that causes it to stop working at 167 pages specifically, so you might just be hitting your device or browser's limits for a single tab for that specific site. 167 is also a huge number of pages for a single tab to handle.

Here are two performance tips to try (both supported in Infy Scroll):

1. If you're appending iframes, try unchecking/unselecting the iframe option
2. You could try enabling Options > Scroll > Page Limit, and have it limit the number of pages so your browser doesn't crash

There's really not much else I can do if your browser decides that's the max it can handle, but I hope this helps.

[grgoffe]

Sixcious

Thanks for responding.

The crash doesn't happen frequently OR predictably but it's suspicious that the URL number always seems to be around 167.

It's an all to frequent problem for coders to malloc without checking the status (and issuing a msg). I would almost bet money that this is the case... somewhere in FF(N)land probably. Sigh.

167 is a "huge" number of URLS so any of the trace type commands I'm familiar with would print a consequentially "huge" amount of output. Maybe Valgrind would show something interesting. What an interesting bug!

I'll keep looking and if I find anything I think you would find interesting I'll let you know.

By the way, this system has 40GB memory so I think it's rather unlikely that this is a memory scarcity issue... I could be wrong though... and, I watch for things like that. Having this much memory has made me a bit lazy about limiting memory requests. Maybe FF(N) about:config has a "max" variable embedded in it somewhere... I'll check. If it is a programmed limitation and I had "control" of the code, I'd pick something like 1000 (or more). As I understand it, infy-scroll is just riding FF(N) so if "they" decide something wonky, "we" all have to suffer... Hmmm... Maybe the FF folks have some ideas.

If you think of anything could you let me know please?

Best regards,

George...

[sixcious]

Hi!

Yes, it could certainly be due to that. It could be the JavaScript or browser engine (in your case, Gecko) not being able to deal with that much data to parse all at once as DOM operations are executed, or the sheer amount of content on the page as it tries to composite and paint/render it as you scroll. I had to add another option (Page Skip) to skip checking pages that had more than 100,000 elements and enabled it by default for everyone because executing a simple document.querySelector() call with more than that amount of elements could cause the browser tab to freeze/crash. Some native infinite scrolling sites try to unload older pages from the DOM as you scroll out of view, which is similar to what the Page Limit option does (you could set it to a high value like 100). If that doesn't work, hopefully, a solution can be found to deal with this!