Chrome page crashes "Aw, Snap. Error 5" after loading too many elements in a page

[DeborahAnn032]

I am on a MacBook Pro M2 with Google Chrome. O am scrolling through a lot of Facebook profiles and I've noticed that after a while the page crashes saying "Aw, Snap". I've tried to increase the browser default cache size but that didn't fix the issue because it's not the problem.
The issue could be in the structure limits of the Blink engine.
So, I thought "what if I delete some of the "upper" elements while I go through it"? That should remove some "weight".

    var profiles = document.querySelectorAll('tagName');
    for(var i=0;i<profiles.length;i++) {
    profiles[i].remove();
    }

As a matter of fact, by doing this I am able to go farther with the scrolling (lazy loading). But a still after a while it crashes.

The new elements are added, and therefore rendered, while scrolling (lazy loading).
I thought: what if I prevent the new elements to be rendered?
Basically I would need to set:

element.style.display = 'none';
but I would need to do this before the element is added, otherwise if I do it after it would be still rendered.
So, I guess I would need to find the script that get the element from server and I would need to make the appropriate changes before it's added.

What I could do?

[floriandiud]

Hello @DeborahAnn032 ,

Thanks for this message.
If you have performance issues, the first things I would do is to close the Developer Console once the script is pasted/submitted. The JS will still be active but you avoid all the "debug layers" that the Developer Console adds.

If this is not enough, you can try to add a "visibility:hidden" style to the list of elements.

Add a "div" at the end to target the children.

And then you close the Developer Console (without reloading the page).

Tell me if this helps.

[DeborahAnn032]

Hello @floriandiud,
thanks so much for replying.
Your guide was very detailed but sadly it still crashes after a while (usually after 6k elements).
Since changing the visibility to hidden didn't work, would be possible to trigger the event that loads the new data, intercept it so that we can prevent to add the data in the div container?
I am asking because I came across a chrome extension (not sure if I can mention it here) that I think does exactly this.

[theninh]

I have same issues, @DeborahAnn032 What is your solution, can you show me?
Thank you so much!!!!

[DhruvAthaide]

@DeborahAnn032 Could you give me the Chrome extension please as I am also facing the same issue!

[paboum]

If you have performance issues, the first things I would do is to close the Developer Console once the script is pasted/submitted. The JS will still be active but you avoid all the "debug layers" that the Developer Console adds.

What performance issues are you talking about? The script just crashes chrome after some 6 or 8k results are fetched (personally I use great xdotool for scrolling page down overnight). Either lower your scripts memory footpring by using optimal algorithms, or consult with chrome dev team on how to increase memory limit for running the script, or perhaps there is a bug in facebook's code and then it would be prudent to report that to facebook (they should in fact allow downloading these records via csv file, saving energy on both client and server side). There is simply no scenario in which user has done something wrong here and should work around the three possible culprits mentioned.

[DhruvAthaide]

If you have performance issues, the first things I would do is to close the Developer Console once the script is pasted/submitted. The JS will still be active but you avoid all the "debug layers" that the Developer Console adds.

What performance issues are you talking about? The script just crashes chrome after some 6 or 8k results are fetched (personally I use great xdotool for scrolling page down overnight). Either lower your scripts memory footpring by using optimal algorithms, or consult with chrome dev team on how to increase memory limit for running the script, or perhaps there is a bug in facebook's code and then it would be prudent to report that to facebook (they should in fact allow downloading these records via csv file, saving energy on both client and server side). There is simply no scenario in which user has done something wrong here and should work around the three possible culprits mentioned.

I think the issue is that everytime you keep on scrolling down the group member list, Facebook keeps on loading the group members that haven't been loaded in and probably add them to the page and after scrolling for about 2 - 3 hours chrome cannot get enough memory to keep on loading new members and sometimes might crash or just slow down. It's a Facebook issue but it might be solved if you have enough RAM on your machine to assign to chrome.

[paboum]

If that's the case, then I see possible approaches:

• The script could modify facebook mechanism and unload redundant data after the users data has been scraped
• The documentation should rougly specify how many users can be loaded with given memory and ask the user to be careful
• The script should somehow learn about free memory and stop operating (block scrolling down further) after the limit
• I have literally 109 GiB of RAM free on my system, I'd expect some runtime flags, ulimit settings etc. could help to make the most of it, and they should be documented here