User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20091010 Iceweasel/3.5.3 (Debian-3.5.3-2) Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20091010 Iceweasel/3.5.3 (Debian-3.5.3-2) After some time http://www.whatwg.org/specs/web-apps/current-work/ is opened, Firefox takes 100% CPU time and completely freezes. Reproducible: Always Steps to Reproduce: 1. Open http://www.whatwg.org/specs/web-apps/current-work/ 2. Wait for a few dozens of seconds. Actual Results: Firefox takes 100% CPU time and freezes (the menus can't be opened, Firefox doesn't redraw anything...). Expected Results: Firefox should work as before.

I can confirm this behavior with the 102509 build of Minefield on Windows 7 Pro x64. Toggling html5, jit.chrome and jit.content to the off position has no affect on this. The above referenced URL also hangs Minefield in safe mode.

It worked way better with Firefox 2 so I think you can call it a regression.

What I did to reproduce: - load page until it is ready - press end key - wait Expected result: a yellow thingy "Last call for comments" should appear on the left. Actual result: takes *very* long until the thingy appears.

Does the problem go away if you run with GECKO_REFLOW_INTERRUPT_MODE=counter GECKO_REFLOW_INTERRUPT_FREQUENCY=1000000 GECKO_REFLOW_INTERRUPT_CHECKS_TO_SKIP=1000000 in your environment?

Mats, it makes no difference adding those values to the Windows 7 Pro x64 system environment.

No differences either under Linux.

http://www.whatwg.org/specs/web-apps/current-work/status.js(which is called from the URL) consumes most processing time.

I think bzbarsky has been doing a good bit of profiling of this page lately and can probably point to a bunch of bugs that will improve things here (a bunch of which are ready to land, I think).

See the dependencies of bug 481131. Fixing bug 526394 should fix most of the "freeze" (which in fact is just us being really slow; after 30+ seconds, how much '+' depends on the machine, the browser starts responding again).

Reopening (this was not a duplicate, see bug 481131 comment 40). The bug (complete freeze) still occurs with: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 Bug 481131 comment 38 says that the hang was fixed in the trunk. So, perhaps this bug should be closed as FIXED (not as a duplicate) with proper references concerning the fix.

Fixed by checkin for bug 526934.

I just checked the URL in this bug with the 16 March build of Minefield and it definitely hangs the browser while the page is loading and then some. And I looked at the bug roc posted, but I don't see a patch submitted or a check-in listed.

Sorry, that's bug 526394. It may be a bit slow but it doesn't hang anything like it used to.

Verified "stop reopening bugs and read bug 481131 comment 42".

Issue is resolved - clearing old keywords - qa-wanted clean-up