understanding "Layout run failure" error logging

Question

I am doing some charting work and got a single line message "Layout run failure" when nothing was being created on the chart. Looking into this I found that I have to add some additional script files to generate the log files as covered here:

Layout Failures

As result of the design for the layout engine in 4.1, it is possible for improper configuration (or a bug) to cause a layout run to fail to complete all of its calculations. When this occurs, the layout simply stops and the partial results that have been flushed to the DOM are all that is visible. In some cases, the layout may be 99% complete and the failure may go undetected or appear as a minor visual anomaly. In other cases, the layout may fail early and leave the UI in a clearly broken state (much like a JS error during layout would do in previous versions).

Diagnostics

The first step if you suspect you are seeing a layout failure is to enable the layout diagnostics. This is done by replacing the normal "ext-all.js" file with "ext-all-dev.js" and adding a couple additional scripts.

I added the required scripts:

<script type="text/javascript" src="extjs/src/diag/layout/Context.js"></script>
<script type="text/javascript" src="extjs/src/diag/layout/ContextItem.js"></script>

And now I get diagnostic data that I can't make any sense of - it doesn't seem to diagnose an error:

++printer<autocontainer> - size: configured/shrinkWrap
    --statprint-1472<autocontainer> - size: configured/configured
        triggeredBy: count=1
            statprint-1472.containerChildrenDone:dom () dirty: false, setBy: ?
        --chart-1473<draw> - size: shrinkWrap/shrinkWrap
            triggeredBy: count=1
                chart-1473.containerChildrenDone:dom (true) dirty: false, setBy: ?
    ++panel-1474<dock> - boxParent: printer - size: natural/configured
    ++panel-1474<autocontainer> - boxParent: printer - size: natural/configured
    ++statprint-1472<dock> - size: configured/configured
        ++statprint-1472_header<body> [isBoxParent] - size: calculated/shrinkWrap
        ++statprint-1472_header<hbox> [isBoxParent] - size: calculated/shrinkWrap
            ++statprint-1472_header_hd<autocomponent> [isBoxParent] - size: calculated/shrinkWrap
            ++tool-1475<autocomponent> [isBoxParent] - size: configured/configured

Does any one know where the diagnostic information is explained?

Short answer is, it's rather complicated. If you could post a test case (as simple as possible) I can try and and help out. — Evan Trimboli, Jul 18 '12 at 03:17
@EvanTrimboli I'll post a new question with the problem that led me into trying to diagnose "Layout run failure". — egerardus, Jul 18 '12 at 15:34
I'm interested can you put a reference link to the question here — VDP, Sep 19 '12 at 14:49
[This](http://stackoverflow.com/q/11545837/1062992) was the question — egerardus, Jan 16 '13 at 02:45
I'm getting the same issue when I mix 'border' and 'vbox' layout. I'm setting 'border' in my viewport which extends 'Ext.container.Viewport', and I have a child (within the 'items' config) in this Viewport view with 'vbox' layout containing two child items. — JustBeingHelpful, Aug 14 '13 at 16:46

score 14 · Accepted Answer · answered Oct 11 '13 at 19:34

14

I find these types of errors are often solved the quickest with a comment-out-till-it-goes-away approach to isolating which component config is causing the layout failure. Comment out child components from the inside out, replacing them with a filler html config, until you zero-in on which component was causing the failure, then see how much you can put back until the error comes back and you should be looking at only a few remaining lines of configuration that you can eyeball against the docs/samples.

answered Oct 11 '13 at 19:34

The Mighty Chris

1,578
13
17

+1 Simple but effective. Just did this when all other methods didn't work or apply. – Matt Jan 14 '14 at 22:44
1

definitely the way to go but its frustrating how somethings that seem to make sense are totally rejected by the layout engine for no apparent reason. I just got one I narrowed down to adding ` align: 'stretch'` to a hbox. I dont why that should ever fail – JonnyRaa Jul 24 '14 at 12:04
Sad but true. Too often I need to resort to it with extjs. – Mike Fuchs Jun 03 '15 at 09:35

score 4 · Answer 2 · answered Mar 28 '13 at 05:06

I was receiving 'Layout run failure' messages in my app and discovered the problem was caused by forgetting to set the layout property inside of my Viewport.js file. Once I defined a layout there, everything worked magnificently well. :)

Example:

Ext.define('MyApp.view.Viewport',{
   extend    : 'Ext.container.Viewport',

   layout  : 'fit',

});

Yellen · Answer 3 · 2015-04-23T17:08:46.483

3

Some of the causes can be attributed as -

Overnesting (look for layouts inside layout. Some layout nested combinations will give this error)
A container is missing a layout.
A container or its children are missing sizing information. For example height/width or flex.
Using ui config on a component that is not defined in the sass.

To debug, we should investigate the layouts in the views where the exception is thrown.

Unfortunately, there is no documentation available.

source: Sencha support

edited Apr 23 '15 at 17:08

answered Apr 23 '15 at 11:59

Yellen

1,785
16
35

1

Wow! The _"layout nested combinations"_ was the key! Thanks! In my case, a `hbox/stretch` inside a `hbox/stretch` made it fail. I changed the inner for `fit` and worked! – Alfonso Nishikawa Oct 06 '17 at 00:12

understanding "Layout run failure" error logging

3 Answers3

Linked