(Update 7-March-2012: the new Page Analyzer described in the blog post has better visualization of layout failures -- removing Sticky on this thread)

First off we want to thank everyone who has downloaded 4.1PR and especially those who have reported their findings. Your input is greatly appreciated.

To assist in this process, we have created a layout "diagnostic layer" that can be used to help isolate the root cause of layout failures. It is enabled by adding a couple script tags after Ext. The two files are not included in normal builds and so cannot be loaded by the dynamic loader (at present). They are located in the src/diag/layout folder in the downloaded zip:

PHP Code:
   <script src="ext-all-debug.js"></script>
   <script src="src/diag/layout/ContextItem.js"></script>
   <script src="src/diag/layout/Context.js"></script> 
You will need a debug console to view the results.

For the vast majority of users, these diagnostics will simply indicate that a layout failure has occurred. Beyond that failure, you can expect problems including JS errors. If a layout failure has occurred, then, it is best to focus only on that issue and not on any subsequent behaviors.

For those that want to write custom layouts, the details from the diagnostic can help identify where results stalled but it will take some time and practice to sort through all the data provided.

A good run will generate a report that says "SUCCESS" while a failed run says "FAILURE". In a failed run, the layout tree is written to the console with "++" indicating completed layouts and "--" indicating unfinished layouts. Something like this (where I have highlighted the missing values):

Code:
-- viewport<absolute>
      triggeredBy: count=3
         ext-gen1003.containerChildrenDone:dom () dirty: false, setBy: ?
         ext-gen1003.height (954) dirty: false, setBy: viewport<autocomponent>
         ext-gen1003.width (1670) dirty: false, setBy: viewport<autocomponent>
   --testA<dock> - ownerCt: viewport
         triggeredBy: count=3
            testA.height (110) dirty: false, setBy: testA<dock>
            testA.width (250) dirty: false, setBy: testA<dock>
            testA_header.height () dirty: false, setBy: ?
      --testA_header<body> - ownerCt: testA
            triggeredBy: count=2
               testA_header.contentHeight () dirty: false, setBy: ?
               testA_header.width (250) dirty: false, setBy: testA<dock>
      --testA_header<hbox> - ownerCt: testA
            triggeredBy: count=2
               testA_header-body.width (239) dirty: false, setBy: testA_header<body>
               tool-1015.width (15) dirty: false, setBy: tool-1015<autocomponent>
         ++testA_header_hd<autocomponent>
         ++tool-1015<autocomponent>
   --testA<autocontainer> - ownerCt: viewport
         triggeredBy: count=3
            testA-body.height () dirty: false, setBy: testA<dock>
            testA-body.width (250) dirty: false, setBy: testA<dock>
            testA.containerChildrenDone:dom (true) dirty: false, setBy: ?
   ++component-1014<autocomponent>
In the above, I deliberately forced the hbox layout to not publish contentHeight (a value published by container layouts when autoHeight) which caused the body layout to stall since it needed that value (it is triggeredBy it) in order to calculate the header's height. This in turn caused the dock layout to stall because it needed the height to dock the header component. Finally, the viewport was waiting for all of its child items to complete before it could perform its final steps.

Hopefully this tool will be of some assistance externally. It has been of great value to us internally as we have been working out the interactions between the many layout managers in Ext JS.