I found that when I go to the Questions page on the Stack Overflow website and browse the pages continuously using the pagination in the bottom of the page, the consumed RAM by stackoverflow.com gets to the point of being several GB and increases the more I continue doing the same.

I am not sure if this is caused by a specific extension, I only have the Grammarly, Mate and Bitwarden Safari extensions installed.

My console shows the following error logged over 3,400 times:

Description below

Blocked script execution in 'about:blank' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

  • 1
    Is this specific to Stack Overflow, the programming Q&A site, or does it happen across Stack Exchange?
    – bobble
    Jan 27 at 15:11
  • @bobble I haven't checked this. I guess it holds for all of them as they are similar, but am not sure.
    – kataba
    Jan 27 at 15:18
  • 4
    This does seem like a Stack Exchange dev problem. otBannerSdk.js is a script file that loads for me as well and announces itself to be the “onetrust-banner-sdk” from OneTrust inc. It can't load in however, and something keeps trying to load it in regardless. The circumstances causing it to fail would be circumstances Stack Exchange devs would need to work on resolving. The screenshot we see represents attempts to insert the same 500kb script 3,500 times which would build a page 1.5gb in size and could grow rapidly. Jan 27 at 15:39
  • 2
    By "browse the pages continuously using the pagination in the bottom of the page" what do you actually mean you're doing? Which pagination on which pages are you using? I'm asking because very few SE/SO pages have actual pagination, and much of that pagination is actually page navigation, rather than loading new resources into the current page, which should completely reload the page. Completely reloading the page should result in all memory resources being used by the page being released. If they are not released, that's a bug in Safari or one of the extensions you're using.
    – Makyen
    Jan 27 at 17:33
  • @Makyen The page looks like is being reloaded on each page change. By pagination, I mean clicking on the orange buttons with page numbers at the very bottom of the Questions page: stackoverflow.com/questions?tab=newest&page=2.
    – kataba
    Jan 27 at 17:39
  • 2
    @kataba Yeah, those are a complete page load. Upon a new page load, all the memory used by the page should be released. The exception to that would be resources the page loads/attempts to load which the browser chooses to hold in its cache. It's possible that the page is attempting to load a resource many times using a different URL each time, causing the browser to fill up its cache. I guess that it's possible Safari doesn't release the memory the page is using in order to allow you to navigate "back" to the page with no interruption. But, then that's a memory management issue in Safari.
    – Makyen
    Jan 27 at 18:05
  • 1
    That doesn't mean there's no issue for SE/OneTrust to address, just that the browser should be preventing any such issue within a page from causing a persistent issue on the system once the page is navigated away from.
    – Makyen
    Jan 27 at 18:07
  • This was retagged as planned an hour ago. Commenting here as tag-only edits don't send notifications. Jan 31 at 22:49
  • 2
    We cannot reproduce this at all, and after reaching out to OneTrust, they cannot reproduce it either. If this is still happening, can you share some exact steps to reproduce it? Feel free to use the Contact Us form if you prefer that route and just put my name in it.
    – SpencerG StaffMod
    Feb 8 at 15:10

1 Answer 1


This does seem like a genuine development problem Stack Exchange devs need to address.

Here's what I can glean is happening:

  • otBannerSdk.js is a third-party library Stack Exchange developers have included on site pages. It loads for me too, and looking at the content of the file, it announces itself as the “onetrust-banner-sdk” from OneTrust LLC. Presumably it's privacy or advertising related; our cookie configuration dialog is managed by OneTrust if you examine its code.
  • Another OneTrust script attempts to load in otBannerSdk.js and have it execute.
  • otBannerSdk.js doesn't have permission to execute in the context it was placed in. An error gets logged that we see in the console.
  • The other OneTrust script that tried to load it notices that otBannerSdk.js hasn't executed and so attempts to load it again, repeating the process.

This would go unnoticed except for wasting some CPU cycles (also bad, but not quite as bad), except it sounds like the script loading it doesn't appear to clean up after itself properly. otBannerSdk.js is a 100kb file that decompresses to an approximately 500kb script. From the scenario described, it sounds like it embeds that 500kb script, then on failing, embeds it again a second time, then a third, and so on. Embedding that 500kb a thousand times this way would add 500 megabytes to the size of the page. Embedding it 3,000 times would add 1.5 gigabytes to the size of the page—and the screenshot shows it loading more than that.

The way this script is loaded and the scenario in which it executes is ultimately something Stack Exchange or OneTrust is responsible for and an error a developer somewhere needs to account for and fix. Something is assuming permissions are available that might not be available in Safari's environment, or might not be available with a privacy addon enabled, in which case the script should still fail gracefully and not accidentally wind up memory bombing a visitor.

That fix might be something Stack Exchange needs to press OneTrust to do, or Stack Exchange might need to simply change how it's using OneTrust's library. Either way, the memory bomb and the CPU wastage should both be fixed; the script should not enter a failure state where it spins its wheels trying to load another script thousands of times and should give up after a limited number of attempts rather than never.

  • 3
    While I agree there's something SE/OneTrust should at least look into, there are hints that the memory problem is actually a Safari or Safari extension issue. A) The "about:blank" page is privileged, so page JavaScript shouldn't affect it. B) If the script was blocked, then it shouldn't be taking up any memory. C) The question OP says that the amount of memory taken up continues to increase when they are browsing between pages. When they switch between pages all memory should be released. It shouldn't be possible for a page to persistently cause a memory leak across page navigations.
    – Makyen
    Jan 27 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .