Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0 ID:20200629154604

With NoScript installed I can see slow-downs and hangs of Firefox when navigating on various sites. The one which completely freezes Firefox is:

https://webdriver-herald.herokuapp.com/

I recorded a Gecko profile and aborted early to be able to capture the profile. Within the 60s 900MB of memory has been allocated. Due to that the Firefox parent process was nearly unresponsive.

I updated to 11.0.32 but it's not better: https://share.firefox.dev/38lr5qj

Another page which behaves strange with NoScript is https://www.tvnow.de/.

Georgio, could you please have a look?

Note that for the network thread a huge amount of CSP related (invalid) URLs can be seen:

https://noscript-csp.invalid/__NoScript_Probe__/

Also see the already referenced bug 1641673. With NoScript enabled we can see a huge amount of setTimeout() calls on https://www.tvnow.de/, which massively slows down the page and causes extra memory allocation.

Just to note, issue subsides when NoScript is set to Allow Globally (Disable restrictions globally).

Sorry for the late answer, but it seems Bugzilla had disabled all my email notifications since mid-April :(

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #1)

Note that for the network thread a huge amount of CSP related (invalid) URLs can be seen:

https://noscript-csp.invalid/__NoScript_Probe__/

These are the CSP violation reports which NoScript intercepts in a webRequest.onBeforeLoad listener in order to record the stuff it's blocking.

In facts, that page sends a barrage of inline script violation reports due to the onmouseover and onmouseout attributes just everywhere (is it normal, though, for them to be fired even if the tab is not the currently displayed one?).

However, the memory killer seems to be the mandatory decoding of the request.requestBody.raw[0] property needed to then JSON.parse() the report. I'm not sure there's something I can do to actually mitigate this issue in browsers older than Firefox 63, other than perhaps trying to filter out inline script violations by examining the raw bytes somehow.

In Firefox >= 63 I can replace all the awful http-based reporting machinery with the newish onSecurityPolicyViolationEvent and filter out the inline script stuff directly from the content script. It's quite a patch, but probably overdue now.

I made the switch to DOM events in https://github.com/hackademix/noscript/releases/tag/11.0.33rc1 and, indeed, this fixes the most visible issue on https://webdriver-herald.herokuapp.com/ , which is the slowdown + massive memory allocation, because I manage to coalesce all the "inline" reports directly in the content script, leading to minimum allocation and IPC.

However now I believe this is a Firefox bug.

NoScript on Chromium-based browsers are completely unaffected because CSP violations are logged/reported on demand, as soon as the code is about to be executed.

On https://webdriver-herald.herokuapp.com/, where there are 8955 onmouseover and 8955 onmouseout inline attributes, Firefox fires 17910 securitypolicyviolationevent instances and, if required, sends 17910 CSP violation reports all at once while the page is loading.
No wonder that any code responding to these events/reports is gonna put the system on its knees.

Chromium just creates 1 report while the page is loading (for an external script), then further reports only when you actually move the mouse on the page, as soon as the onmouse* handlers are actually triggered.

Filing another bug in Core/Security to have this investigated.

Thanks a lot for the fix. Do you already have an ETA when the new version will be released?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #6)

Thanks a lot for the fix. Do you already have an ETA when the new version will be released?

You can already try 11.0.33rc1 from the link above or https://noscript.net/getit#devel, as it is signed for external hosting.

I'm submitting 11.0.33 "stable" to AMO right now. Since it's a recommended extension, it'll get some hours up to a couple of days to be reviewed.

It should be live now.

And that works great! Thanks again for that quick fix!

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #8)

It should be live now.

Sorry, I need an expedite review for 11.0.34 which fixes an unexpected nasty regression in 11.0.13 (Google searches go in a refresh loop when google.com is not TRUSTED) :(

Thank you!

It's been reviewed, luckily just before EOW.

Feel free to email me if there's an emergency in the future Giorgio.