[FIXED] [#280] "Layout run failed" appears when displaying large no of dynamic MenuPanels inside Portals inside GroupTabPanel

[michaeld]

I have not been able to reproduce the condition using static controls. This behavior has been witnessed by Daniil on my website. Stepping through the code, it appears that watchDog counter inside counts to zero. It appears one of the controls cannot resolve vertical and does not allow the remainingLayouts to decline which causes the watchDog to elapse.

It does not appear to affect the output or the page however, so I don't know if it's serious or worthy of concern. :shrug:

[Daniil]

Hi @michaeld,

Thank you for starting a new thread.

It does not appear to affect the output or the page however, so I don't know if it's serious or worthy of concern. :shrug:

I feel it might be serious, e.g. might cause to some unpredictable behavior.

The Ext.onReady() script of your page is about 1500 code lines. There is a very tiny chance to catch the problem point just investing/looking at this script.

So, I tried to debug.

[E] Layout run failed allowed me to find the place where the error is logged, but, unfortunately, it gives no clue what is the container and layout that the error happens with.

The only thing I can see there is the Ext.remainingLayouts is more than 0, so, it means there was unsuccessful layout. But, as I said, no information about what the failed layout was. I have to ask Sehcna about that. Resolving such issues can make the developers crazy.

I found this thread:
http://www.sencha.com/forum/showthread.php?256500

The only suggestion is to run the page in Page Analyzer. I doubt a bit it will help, though I am not very experienced in Page Analyzer. So, I am not aware of all its possibilities. Moreover, Don Griffin is a very respectable person, so, it might be best just to try his suggestion mutely. Unfortunately, I cannot do it myself, since Page Analyzer and the actual page should be deployed on the same server. Can you do that?

[Daniil]

Wait a bit with Page Analyzer. I have an idea how to catch a failed layout. I will give that idea a try on Monday. Is that OK for you?

[michaeld]

Sure, and I agree.

However, what I tracked remainingLayouts, the watchDog works fine. I do wonder if 100 is even remotely enough given the number of times this section of code reloops through. It depends on the complexity and what triggers the loop to repeat without having all layouts resolve. What's worse is new remainingLayouts appear based on certain conditions of resolving another layout and remaining bounce back up. I saw remainingLayouts bounce from the final 1 back up to 79 before it settled and broke at 53. Honestly, this is a complex section of code and I'm sure there is some reason for the decisions and the madness, but the real failure from what I can tell comes down to when the remaining count does not change at all because a layout actually failed somewhere along the line and repeated attempts does not resolve the matter. That's why the watchDog is there; to kick out and prevent an endless loop.

However, it's like you said. This section of code does not tell you which control the error is appearing. I can tell you from my own diagnosis it came down to dock-1123, dock-1131, dock-1141 and dock-????. I didn't check the last one. I looked at the rendered html and these ids did not appear in the code which may simply only tell me that because they didn't render. Sigh, but I'm still novice trying to track back the parents but I did determine it was elements supposed to be created within the portlet. It doesn't make sense given I've looked at the extjs output json and they are all created consistently the same so whatever is causing it is going to be painful to find because it's a bug in extjs, not the extjs json. What makes this hardest of all is it seems only to appear in massive designs with thousands of controls. That's why I couldn't recreate it.

Please do give it a try Monday. I'm in no rush at this juncture. Eventually I will have thousands of more entries in this section and will have to come up with a dynamic update that doesn't load everything at once, but till then, this layout issue plagues. For now I don't know the impact, but I will by the time I launch.

[Daniil]

I was able to catch a crashed layout. Here are some details how:
http://www.sencha.com/forum/showthre...500#post974556

The "column" layout is crashing and its container is "portalpanel-1020". It is the PortPanel with the "Music Oriented" title.

Please try to remove/comment that PortPanel. Is the issue going away?

Can we also try the page analyzer with your page? I am very curious it will allow to catch a crashed layout or not.

[michaeld]

The "column" layout is crashing and its container is "portalpanel-1020". It is the PortPanel with the "Music Oriented" title.

Please try to remove/comment that PortPanel. Is the issue going away?

When I step over the creation of the entire Music Oriented tab, the Layout error does go away.

Can we also try the page analyzer with your page? I am very curious it will allow to catch a crashed layout or not.

I do not understand what exactly you are asking. I keep hearing about the page analyzer but I'm not sure I know what it is or what it entails. I do believe you can save the html file from my page and run it just as effectively outside of the application or my server and manually tweak that html till the error disappears. Or thus run it in any external application or parser.

[michaeld]

I have determined that the layout does not fail if I give the browser more vertical space than the current preset height of the parent of the GroupTabPanel or if I remove the height altogether, this warning goes away. I'm also finding that once the layout fails, resize doesn't work on this page.

Which brings me to the issue I was having that caused me to put a height in there at all. I don't use height almost ever in any of my controls. I rather let the page resize with the available space and use autoscroll for the height. The parent of the grouptabpanel was the only control I've found that has not been able to manage this without a height.

[michaeld]

Since the post above, I further investigated the question why height was needed at all and I looked more closely at the parent containers. One of the main parents "P" was not given a Flex, though it was a part of a parent vbox with a stretch. This single missing attribute seemed to affect this entire page and didn't really cause anything to blow up until thousands of children later. I cannot tell you why this single missing parent attribute caused the layout failure at such a low level. I cannot tell you if page analyzer would have made it easier to find this discrepancy either, but I can say that nothing in the logging, even the suggestion you made to sencha would have made it any more apparent that the true cause was 25 nested parents earlier in the layout render stream. It's a shame nothing is logged to clue. I can imagine someone taking days tracking these issues down. I guess in retrospect, it sort of did. I just got lucky that I decided to investigate again why I could not get this control to resize properly.

I'll leave my production website available if you still want to look at it through analyzer and see if this issue would have shaken out, but I do need to push a new version to production as soon as possible. Let me know when you've had a chance to look. Thanks for your time and help.

[Daniil]

Can we also try the page analyzer with your page? I am very curious it will allow to catch a crashed layout or not.

I do not understand what exactly you are asking. I keep hearing about the page analyzer but I'm not sure I know what it is or what it entails.

Page Analyzer is a nice feature to master. More details about that you can find following the link which @Don posted here:
http://www.sencha.com/forum/showthre...500#post938886

I do believe you can save the html file from my page and run it just as effectively outside of the application or my server and manually tweak that html till the error disappears. Or thus run it in any external application or parser.

Well, I can. Though it requires some manage/tweak of resource URLs to get the page runnable. Generally, I just thought you might what to give Page Analyzer a try yourself. Finally, I tried it myself and, indeed, it does show a failed layout.
http://www.sencha.com/forum/showthre...500#post974847

I'm also finding that once the layout fails, resize doesn't work on this page.

I recall this dialog:)

It does not appear to affect the output or the page however, so I don't know if it's serious or worthy of concern. :shrug:

I feel it might be serious, e.g. might cause to some unpredictable behavior.

Re: resolution

Yes, it is shame that there are no more specific clues ExtJS/Ext.NET provides on such layout failures.

Please bear in mind the following rule: VBox does require Height or Flex settings for its items; HBox does require Width or Flex setting for its items.

I'll leave my production website available if you still want to look at it through analyzer and see if this issue would have shaken out, but I do need to push a new version to production as soon as possible. Let me know when you've had a chance to look. Thanks for your time and help.

Please go ahead, I have already tried it with Page Analyzer and now have a local version of the page if I maybe need of it again to finalize the Sencha thread.

[michaeld]

Re: resolution

Yes, it is shame that there are no more specific clues ExtJS/Ext.NET provides on such layout failures.

Please bear in mind the following rule: VBox does require Height or Flex settings for its items; HBox does require Width or Flex setting for its items.

Yeah. Yet, there is no diagnostic mode to detect this basic detail. The layout will still try like heck. Hmmmm. Anyway, that's a suggestion for sencha.