Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3437 closed defect (invalid)

dijit.layout.PageContainer widget shrinks every window.onresize with certain CSS on FireFox 2

Reported by: guest Owned by: bill
Priority: high Milestone: 0.9beta
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description

See the attached PageContainer_bug1.html in Firefox 2.0 (IE6 doesn't exhibit this problem). Everytime the window is resized, the contents below the dijit.layout.PageContainer? will creep up the page. Via FireBug? I can see that style.height keeps getting smaller.

I haven't been able to trace this completely, because I don't fully understand the dijit code, but the dijit.base.Sizable.resize() function seems to be heavily involved.

Here is my guess as to what is happening:

(1) The window.onresize event is fired and the dijit.layout.PageContainer?.resize() function (inherited from dijit.base.Sizable) gets called.

(2) It calculates this._contentBox and calls dijit.layout.PageContainer?.layout() which will call this.selectedChildWidget.resize(this._contentBox)

(3) this.selectedChildWidget in this case is the dijit.layout.ContentPane?, which also inherits its resize() function from dijit.base.Sizable.

(4) The dijit.layout.ContentPane? will be resized via dojo.marginBox() in dijit.base.Sizable.resize() to be the size of the dijit.layout.PageContainer?'s this._contentBox above.

And now for the mystery step

(5) The next time this._contentBox is calculated for the dijit.layout.PageContainer?, it will somehow be smaller after the dijit.layout.ContentPane? has been resized in step #4.

This badness could be comming from many places. My random guess would be dojo.marginBox() under these conditions will either calculate the margin box incorrectly, or set it incorrectly.

The other attached pages help show exactly what "under these conditions" means. Basically this is caused by styling the node used by dijit.layout.ContentPane? to have greater margin/padding.

You can see this, because the problem won't occur when either: the styles are moved into a sub-div below the ContentPane? (like in PageContainer_bug2.html) or the margin/padding styles are removed (like in PageContainer_bug3.html).

I will keep investigating this problem and add more comments if I can pin-point this more narrowly.

Attachments (3)

PageContainer_bug1.html (899 bytes) - added by guest 12 years ago.
Shows the bug!
PageContainer_bug2.html (970 bytes) - added by guest 12 years ago.
Minor change that doesn't show the bug.
PageContainer_bug3.html (1.0 KB) - added by guest 12 years ago.
Another minor change that doesn't show the bug.

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by guest

Attachment: PageContainer_bug1.html added

Shows the bug!

Changed 12 years ago by guest

Attachment: PageContainer_bug2.html added

Minor change that doesn't show the bug.

Changed 12 years ago by guest

Attachment: PageContainer_bug3.html added

Another minor change that doesn't show the bug.

comment:1 Changed 12 years ago by bill

Resolution: invalid
Status: newclosed

Hi there. You need to have a size specified for the page container. If you want it to be full screen, try following the pattern in themeTester.html, setting width=height=100% for html, body, and the PageContainer? node. Otherwise just put in some size like width=100%, height=500px.

comment:2 Changed 12 years ago by bill

PS: or if you don't want layout (if you want the pagecontainer to not do anything related to sizing) then set PageContainer?'s doLayout=false.

comment:3 Changed 12 years ago by guest

Ah, ok! What I really needed was doLayout=false, because I don't care about the size, I just want it to be the size of the selectedChild. I ended up using widgets that aren't dijit.layout.ContentPane? (and don't have a .resize() function), so the layout doesn't do anything for me anymore anyway.

Maybe doLayout=false is a good default for PageContainer?? The results are kind of unexpected.

comment:4 Changed 12 years ago by bill

Yeah perhaps. Actually I'd like the doLayout setting to be automatic based on whether the user has specified a height or not, but I don't know how to detect that. (I can check node.style but what if the user has set the height via CSS rules?)

comment:5 Changed 12 years ago by guest

The thing is, even if the user doesn't specify a height, the doLayout=true will actually work correctly in most situations. That is to say, it will resize the selectedChild to be exactly the size it was already.

The only situation it doesn't work, is when the user sets greater than 0 margin/padding of the node that is being resized (via dojo.marginBox). This is why I thought it was a bug. Because (1) everything works as you expect it until you decide to add margin/padding to your ContentPane? AND (2) the unexpected behavior only happens under Firefox (IE is fine!).

The best thing, would be if it could resize the selectedChild to the size it was already even with greater than 0 margin or padding. This way everything would act consistently. It would still be better to set doLayout=false in such a situation to eliminate the useless resize, but at least no unexpected behavior creeps in when switching browsers or loading an unknown widget into your PageContainer?.

Note: See TracTickets for help on using tickets.