too many nested VerticalLayout objects in firefox causes failure

I’ve search around the forums for any information on this issue which is absolutely reproducible - in FireFox 10 & 11 (perhaps earlier as well), if there are more than 26 VerticalLayout placed inside one another, the browser wont show 27+ Layout. The exact same code will work fine in IE9, Chrome.
FYI: 27 nested VerticalPanel translates into ~192

tags when viewed via FireBug’s DOM tool.

We’re using Vaadin to build large UI farmework for our products and we do have a realistic need for such a heavy depth of nested panels.

I’m surprised this issue has not been discussed much in these forums.

Any help or insight is appreciated.

The code below will reproduce the issue in FireFox 10 & 11.
(change the for loop from 27 to 26 and DEEP-CHILD will display)

 public class TestvaadinApplication extends Application {

public void init() {
	
	Window mainWindow = new Window("Nested Layout Application");
	setMainWindow(mainWindow);
	
            VerticalLayout last = new VerticalLayout();
            VerticalLayout top = last;
            for(int i=0; i < 27; i++ ) {
    	        VerticalLayout rp = new VerticalLayout();
                    rp.setMargin(false);
    	        last.addComponent(rp);
    	        last = rp;
            }
            
            Label deepChild = new Label("DEEP CHILD");
            last.addComponent(deepChild);
    
            mainWindow.addComponent(top);
    
}

}

You are surprised others haven’t tried to nest more than 26 VerticalLayouts one inside the other? :open_mouth:

I’d be interested in your “realistic need.” Sounds odd to me, but you never know, maybe there’s an alternative way to achieve the effect you want.

Besides this problem, never nest that must vertical layouts. This will perform bad, because of all the javascript calculations. Use another layout like like CssLayout

Being that this ]very page
uses 10 nested DIV
tags just to display these comments - it doesn’t seem to be to large of a leap to consider a more complex WebApp (not a simple webpage) might have more than 26 DIV but that’s not really the point of my question.

While I realize that 1 VerticalLayout doesn’t simply equate to 1 DIV tag, I was curious whether anyone else had an work-around or at least understood the nature of the problem - I do recognize that I am pushing the framework further than a typical usage but from a DOM perspective there’s no inherent problem with such a heavily nested set of DIV and
at 25 the Javascript performance is fine.

Given this problem only appears on FireFox so it seems to me that it’s not a limitation to either the DOM or Javascript and might just a be bug that might be easily fixed.
I might very well invest the time to build a custom VAADIN component that isn’t as heavy as VerticalLayout (which created about 4 or 5 DIVs per instance depending on the alignments and margins, etc).

thanks in advance

CssLayout actually is light enough to serve this purposes and will work better than VerticalLayout in our unique situation. thanks.

Firefox has a nesting limit, and other browsers may or may not have different limits. I am not certain if the nesting limit is on the DOM level or the render tree level, but for all practical purposes, you seem to have found the cut-off point.

The reason VerticalLayout has so many nested DIVs is to be able to support all its features (including margins and spacing, alignments, …) and especially to be able to support them on older browsers (think IE6) with their limitations, including in CSS handling. As already noted, CssLayout is much lighter at the cost of a smaller feature set and potentially needing to do some things on the CSS level.

thanks Henri.

I would like to reaffirm the alternative approach suggested by others. We ever faced the similar problem in the past. Performance degraded with intensive use of HorizontalLayout / VerticalLayout / GridLayout. Switching to CssLayout and CustomLayout improved the performance significantly with the trade-off of manually writing additional cross-browser compliant CSS for corresponding layout. Still, the performance improvement pays for the extra effort.