I just noticed a bug in the FolderTree widget. It is setting its size based on the first ancestor widget, not parent dom node. That means if your FolderTree is in a div or anything not widget, it will take the size of the first ancestor widget, which can be a lot bigger than the dom element it is in and give you some weird behavior.
To fix this, wrap it in a BorderContainer, ContentPane or any sort of widget, or override the resize method to behave nicely with your configuration.
Here is the source of the issue, in the ecm.widget.FolderTree class:
/** * Resizes the tree. */ resize: function() { var pn = this.getParent(); if (pn) { if (pn.titleBarNode != null) { domGeom.setMarginBox(this.domNode, domGeom.getContentBox(pn.containerNode)); } else { domGeom.setMarginBox(this.domNode, domGeom.getContentBox(pn.domNode)); } } if (this._tree && this._tree.domNode) { this._tree.resize(domGeom.getMarginBox(this.domNode)); } }
The this.getParent() is returning the first widget ancestor, so it will act nicely if your widget is directly in another widget (as you can see it knows how to deal with widget having a container node). But if like me, you added it in some nested div in a dialog, the first widget parent is the dialog itself, and it will set the size based on the dialog instead of the content area (which is a dojo attach-point), which is way to big. For my use case, I fixed it the following way:
this.folderTree.resize = function () { var pn = this.getParent(); // pn in our case is the BaseDialog widget, and we know our FolderTree // widget is the only one in the contentArea node, so we can fit the // whole space in the contentArea, of course that's really specific if (pn && pn.contentArea) { var box = domGeom.getContentBox(pn.contentArea); // GetContentBox returns the actual size and offsets of the parent, // we don't want to use the same offsets for the child domGeom.setMarginBox(this.domNode, {l: 0, t: 0, h: box.h, w: box.w}); } if (this._tree && this._tree.domNode) { // Resizing the inner tree this._tree.resize(domGeom.getMarginBox(this.domNode)); } };
That works because the content dialog has a contentArea attach-point. However that’s really specific so the best way to work around this bug would be to just wrap your FolderTree in another widget.
do you know if this is still occurring in ICN 3.0.7? we would like our folder tree div to expand to at least the largest folder in the parent hierarchy.