- It's not JavaScript; it's the fact that there are many complex Scalable Vector Graphics (SVG) files being rendered by the link you posted.
- Fedora's hardware-accelerated graphics stack is notoriously buggy, so it is quite possible that Firefox's use of the graphics stack is causing a bug in the graphics stack (in Mesa, the Xorg DDX, or the kernel).
- It is also possible that the SVGs are being rendered actually in software and the software renderer is still buggy.
Let's divide and conquer:
Disable Hardware Acceleration
In FF, go to Edit -> Preferences, click Advanced, then under the General tab, in the Browsing section, uncheck "Use hardware acceleration when available".
Now try the same site again. If you don't get CPU/memory overload, then we know that the problem is either in the 2D Canvas GPU acceleration (either Firefox's use of it, or in the backend graphics stack), or in the SVG renderer.
If you do get the same CPU/memory overload with hardware accel disabled, then it could be a bug in the SVG parser, which is probably done in pure software. Although, in that case, we would probably experience the problem on Windows as well, but we aren't (tested on FF 24.1.0 on Windows and it was slow, but not consuming all CPU and RAM like yours).
I suspect some kind of memory leak in Mesa.
A few more things to try
- Go to
about:support in Firefox, click "Copy text to clipboard", and post that here (pastebin or so). This will help those of us familiar with the problem-space to determine what the situation is with your hardware and your graphics stack.
- Go to
about:memory in Firefox, check the "Verbose" checkbox, then click "Measure". It would be awesome if you could do this just after you go to the offending page -- if you're able to get FF to do anything at that time.
- Run Firefox from the terminal as follows:
LIBGL_DEBUG=verbose firefox -safe-mode. Navigate straight to the site that OOMs. Let it run for just a few seconds (enough to clearly start the problem, but don't let it overwhelm your system) then kill it. Post the output here, along with the output of dmesg.
These things will give us more debug info to understand exactly where the problem is, but most of these steps are focused around the assumption that the problem is in the graphics stack. If it isn't, most of this won't be helpful.
Update: I created a raw github link that has no javascript or any tomfoolery whatsoever; it's just a laundry list of SVGs. It should crash if you have the defective behaviour, and it eliminates all other possible sources of the problem.
Update 2: The OP isolated the problem to this specific image.
Best Answer
I suspect it is either the Garbage Collector or the Cycle Collector.
In
about:configchangejavascript.options.mem.logtotrue. Now notices about GC and CC should be available in the Error console (Crtl+Shift+J) If their timing and duration matcher the freezing, then this is your problem.When I had this problem I fixed it by blowing away my Firefox profile and creating a new one from scratch. The Firefox profiles have a tendency to gather a lot of crud over time.
Even this is not a prefect solution. If you open a lot of tabs in Firefox (100+) or lots of extensions and leave Firefox running for days on end it will inevitably slow down. You will need to restart Firefox every once in a while.
If you are like me and have a tendency gather a large collection of tabs you need get around to dealing with at some point another trick I use is to set
browser.sessionstore.max_concurrent_tabsto 0. This will stop Firefox from loading all the tabs of your session when starting. It will instead load them when you switch to them. I find this, plus the occasional restart of Firefox, greatly reduces the load of having a great many tabs.