Andreas Pietzowski Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20170628075643

Steps to reproduce:

Just enter www.der-postillon.de in the location bar. I can reproduce only under Mac OS X. Under Linux the site loads fast as normal.


Actual results:

Firefox consumes 100 % CPU for about 30 seconds - then it is responsive again.


Expected results:

Immedaite loading like under Linux

	Abe - QA (:Abe_LV)
	Comment 1 • 7 years ago

Hi Andreas,

I have tested this on OSX 10.12 with latest nightly, but couldn't manage to reproduce.

Could you please provide the memory report? Thanks

Here are the steps to generate a memory report:

1. Wait until memory usage is high
2. Open a new tab and type "about:memory" into the address bar and hit enter
3. Click on the "Measure and save..." button
4. Attach the file to this bug.

Detailed information is available here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/about:memory

	Andreas Pietzowski Reporter
	Comment 2 • 7 years ago

Here you go. I hope this helps. Otherwise leave a comment.

Thanks
Andreas

	Abe - QA (:Abe_LV)
	Comment 3 • 7 years ago

Hi Eric,

Comment/suggestion on this memory report, comment 2? Thanks

	Eric Rahm [:erahm]
	Comment 4 • 7 years ago

It looks like you have a lot of ghost windows:

> 26 ── ghost-windows

My guess is that an add-on is keeping these alive. Can you provide a list of extensions you use from about:support?

The best way to figure out which add-on is causing problems is to disable all add-ons and see if that fixes your issues, then selectively re-enable them. A quick test is to start in safe mode [1].

[1] https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode

	Andreas Pietzowski Reporter
	Comment 5 • 7 years ago

I disabled all my extensions and the page loads fast! Ok, the odd man out is NoScript: https://noscript.net/

When I enable it under Mac OS, this page triggers 100% for 30 seconds or more. Strange. MAybe it is a special rule in there. I have thousands of rules over the years...

I guess it is hard to reproduce what is the real reason, right?

	Tobias C. Berner
	Comment 6 • 7 years ago

Hi 

I notice the same behaviour with Firefox 54 on FreeBSD on that site -- Firefox's ui is completly unresponsive for a while.


mfg Tobias

	Andreas Pietzowski Reporter
	Comment 7 • 7 years ago

Do you also have the extension NoScript activated?

	Tobias C. Berner
	Comment 8 • 7 years ago

Yes, and it seems indeed to be the cause for it, as removing it makes the site load properly.

	Andreas Pietzowski Reporter
	Comment 9 • 7 years ago

I already contacted the developers over software@informaction.com but no response yet since one week ;-(

I also whitelisted all referenced sites but no success. Only complete disabling NoScript makes the site loading. Any ideas what we can do?

	Eric Rahm [:erahm]
	Comment 10 • 7 years ago

Jorge, can you try to get a hold of the NoScript folks?

	Eric Rahm [:erahm]
	Comment 11 • 7 years ago

(Amy and Shell, kev suggested you might be able to help as well)

	:shell escalante
	Comment 12 • 7 years ago

emailed giorgio (cc: erahm) to ask about this bug

	Giorgio Maone [:ma1]
	Comment 13 • 7 years ago

We've been investigating this for a while in NoScript's support forum (https://forums.informaction.com/viewtopic.php?f=10&t=22828).

Should be fixed in 5.0.8rc1 (https://noscript.net/getit#devel), please check, thanks.

	Andreas Pietzowski Reporter
	Comment 14 • 7 years ago

But isn't it somehow also a bug of firefox? The scripts freezes firefox completely. Sometimes for minutes and I have to kill -9 it. An extension should not cause such issues. What do you think?

	Giorgio Maone [:ma1]
	Comment 15 • 7 years ago

(In reply to Andreas Pietzowski from comment #14)
> But isn't it somehow also a bug of firefox? The scripts freezes firefox
> completely. Sometimes for minutes and I have to kill -9 it. An extension
> should not cause such issues. What do you think?

Kind of. Actually the XSS filter sets the "slow script" warning timeout to 40 seconds, after which - if user have chosen to stop the script - it should force the filter to fail on a "potential DOS attempt", but this is apparently not working as expected anymore.

Anyway it shouldn't happen anymore in out-of-process WebExtensions, which should be unable to block the main thread with background processing (that's not the case for content scripts, but I guess they're gonna be limited by the same time constraints / DOS mitigations applying to the Web).

	Tobias C. Berner
	Comment 16 • 7 years ago

The development version seems to fix it. Thanks.

	Andreas Pietzowski Reporter
	Comment 17 • 7 years ago

I can confirm tat the bug is gone with NoScript update to the development trunk version. Meanwhile the solution is to deactivate XSS configurations in the NoScript options menu.

Thanks for this fast and collaborative investigating!

	Eric Rahm [:erahm]
	Comment 18 • 7 years ago

Sounds like this is fixed, lets go ahead and close.