Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#8410 closed defect (fixed)

[dojox.layout] FloatingPane throws "dim is undefined" with multiple nested FloatingPanes

Reported by: randycasburn Owned by: dante
Priority: high Milestone: 1.4
Component: DojoX Layout Version: 1.2.3
Keywords: FloatingPane resize _layoutChildren Cc:
Blocked By: Blocking:


When placing multiple FloatingPanes? as children of the same ContentPane?, FloatingPane? halts execution with subject error.

I have failed to trace this to the source other than to link it to the _layoutChildren method of ContentPane? and more specifically to the resize method of FloatingPane?.

I have attached an image of the the sequence and as you'll see, just before the fault, a properly formed object is not sent to the resize method as required. ('nothing' as shown in the image).

What actually has happen AFAIK, is an extra call to resize has been made with an empty object as it's source.

I simply don't have the depth to discover the source of this error.

Attached you'll find a test case and the image described above.

Attachments (3)

test_FloatingPane_dim_error.html (7.5 KB) - added by randycasburn 10 years ago.
test with dim error
dim_dump.jpg (38.0 KB) - added by randycasburn 10 years ago.
FireBug? dump of error
fp.patch (1021 bytes) - added by dante 10 years ago.
try this fix. slightly smaller. some style cleanups too

Download all attachments as: .zip

Change History (12)

Changed 10 years ago by randycasburn

test with dim error

Changed 10 years ago by randycasburn

Attachment: dim_dump.jpg added

FireBug? dump of error

comment:1 Changed 10 years ago by randycasburn

I did also mean to mention that I do think this is related to ticket:8408.


comment:2 Changed 10 years ago by bill

Randy, you are right. resize() for dijit layout widgets takes an optional size argument, but FloatingPane's resize()'s argument is not optional, leading to the problem.

resize() called without an argument really means "you have been made visible so size yourself".

comment:3 Changed 10 years ago by dante

Milestone: 1.31.4

bill: so FloatingPane? should adjust for that semantic?

comment:4 Changed 10 years ago by bill

Right, please adjust to that semantic... I think if there's no argument then just call the layout function that's generally called when the floating pane starts up (if there is such a function).

comment:5 Changed 10 years ago by randycasburn

Hey Dante,

Know this isn't on top of the list, but wanted to offer a very easy solution to this ticket so you can put this one behind you. This fix works consistently across platforms/browsers I am able to test, but that is somewhat limited.

All code offered is for dojox.layout.FloatingPane?.

1st -- Add this line to the postCreate() method:

        this._naturalState = dojo.coords(this.domNode);

As you can see it simply promotes your use of the _naturalState semaphor earlier in the class and allows use of this object later in the resize method as seen below.

2nd -- Mod the resize() method as follows:

        resize: function(/* Object */dim){
        // From a reDraw event we get NOTHING! Set back to default state
        if (typeof dim == 'undefined') {
             dim = this._naturalState;
                // summary: Size the FloatingPane and place accordingly
                this._currentState = dim;

                // From the ResizeHandle we only get width and height information
                var dns =;

As you can see, we simply validate the object in our required method and assign it our _naturalState member object value if it is 'unset'.

This has worked beautifully for me in my application, so I thought I would offer back to you as a fix.

Hope this is helpful,


comment:6 Changed 10 years ago by dante

sweet. thanks for stepping up. Do you have a CLA on file by chance? I like to attribute the fixes to whomever. Sorry for overlooking this so long, I secretly want FloatingPane? to have a new owner :)

comment:7 Changed 10 years ago by dante


// in resize()
		dim = dim || this._naturalState;

would suffice? trying to read coords() in postcreate makes me nervous, and may break the case where a FP is made with no srcNodeRef, but apparently this problem only exists when ContentPane? passes along resize to children now?

Changed 10 years ago by dante

Attachment: fp.patch added

try this fix. slightly smaller. some style cleanups too

comment:8 Changed 10 years ago by dante

Resolution: fixed
Status: newclosed

(In [20319]) fixes #8410 - moving forward with my original suggested update to the issue, which is a smaller version of randy's suggestion

comment:9 Changed 9 years ago by bill

Component: DojoX WidgetsDojoX Layout
Note: See TracTickets for help on using tickets.