understanding "Layout run failure" error logging

Asked 18/7, 2012 at 3:12 Answered 23/4, 2015 at 11:59

Solved debugging logging extjs extjs4 extjs4.1

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?

Connotation answered 18/7, 2012 at 3:12 Comment(5)

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. – Bal 18/7, 2012 at 3:17

@EvanTrimboli I'll post a new question with the problem that led me into trying to diagnose "Layout run failure". – Connotation 18/7, 2012 at 15:34

I'm interested can you put a reference link to the question here – Authorship 19/9, 2012 at 14:49

This was the question – Connotation 16/1, 2013 at 2: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. – Voltmeter 14/8, 2013 at 16:46

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.

Pace answered 11/10, 2013 at 19:34 Comment(3)

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

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 – Tom 24/7, 2014 at 12:4

Sad but true. Too often I need to resort to it with extjs. – Hallucinatory 3/6, 2015 at 9:35

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',

});

Aubyn answered 28/3, 2013 at 5:6 Comment(0)

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

Emission answered 23/4, 2015 at 11:59 Comment(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! – Plexor 6/10, 2017 at 0:12

Recommended topics

Hot tags