524436 - Firefox takes 100% CPU time and hangs/freezes on http://www.whatwg.org/specs/web-apps/current-work/

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Vincent Lefevre]

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.

Comment 1

[Brian Carpenter [:geeknik]]

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.

Comment 2

[Ria Klaassen (not reading all bugmail)]

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

Comment 3

[Ria Klaassen (not reading all bugmail)]

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.

Comment 4

[Mats Palmgren (inactive)]

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?

Comment 5

[Brian Carpenter [:geeknik]]

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

Comment 6

[Vincent Lefevre]

No differences either under Linux.

Comment 8

[Alice0775 White]

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

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).

Comment 10

[Boris Zbarsky [:bzbarsky]]

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).

Comment 11

[Vincent Lefevre]

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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fixed by checkin for bug 526934.

Comment 13

[Brian Carpenter [:geeknik]]

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.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sorry, that's bug 526394.

It may be a bit slow but it doesn't hang anything like it used to.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Joshua Mitchell (Inactive)]

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