User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1
Build ID: 20111004030858
Steps to reproduce:
1) Open http://forum.shrimprefuge.be/showpost.php?p=833327&postcount=1342 in a tab.
2) Click 'Toon' button.
3) Click 'Verklein' button, close the tab or close Firefox.
Firefox will hang and soak up a CPU core completely every single time.
The page should return to the state it was in before clicking the 'Toon' button.
The hang occurs with the latest nightly, but not with the latest Aurora build. Managed to trigger the hang consistently on:
-Windows 7 64bit using both 32 and 64bit nightlies
-Ubuntu 10.10 32bit running in VirtualBox
confirming with Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111003 Firefox/10.0a1 SeaMonkey/2.7a1
This works with FF7.0.1
Will try to find a regression range and or stack trace later
Regression window(m-c hourly)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929122038
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929141938
My money is on Ehsan here....
Created attachment 564607 [details]
Looks like a RecreateFramesForContent leading to lots of CaptureFrameState..... Are we just recreating over and over or something else?
Created attachment 564647 [details]
Created attachment 565344 [details] [diff] [review]
This was a stupid mistake that I made. nsTableOuterFrame::GetChildLists was returning the principal child list twice.
This patch https://hg.mozilla.org/mozilla-central/rev/306153bf7a41 was effectively wallpapering over this bug... :-)
So I backed it out now that this is fixed for real:
Try run for 2b3b601727a6 is complete.
Detailed breakdown of the results available here:
Results (out of 193 total builds):
Builds available at http://firstname.lastname@example.org
Now that we have a better understanding of this bug, is it of enough concern (and the patch low enough risk) to consider for Beta 10?
Sorry, missed that this was fixed on 10 already. Disregard the above.