Opened 9 years ago

Closed 9 years ago

#12372 closed defect (fixed)

BorderContainer with ContentPanes inside dijit.form.Form broken since 1.6.0

Reported by: Florian Owned by: bill
Priority: high Milestone: 1.6.1
Component: Dijit Version: 1.6.0
Keywords: dijit..layout.BorderContainer dijit..layout.ContentPane dijit.form.Form Cc:
Blocked By: Blocking:

Description (last modified by bill)

When embedding a BorderContainer with ContentPanes inside a dijit.form.Form the BorderContainer is not rendered correctly. This was working until 1.6.0rc1 but not with 1.6.0 anymore.

Example:

[...]
<style type="text/css">
html, body {
	height: 100%;
	width:100%; 
	margin: 0;
	overflow: hidden;
}
</style>

[...]

<body class="claro">

<form dojoType="dijit.form.Form"
		style="height:100%;width:100%;display:inline;"> 
	<div dojoType="dijit.layout.BorderContainer" style="height:100%;width:100%;">
		<div dojoType="dijit.layout.ContentPane" region="top">
			title
		</div>
		<div dojoType="dijit.layout.ContentPane" region="center">
			A dijit.form.FilteringSelect just for testing: 
			<select dojoType="dijit.form.FilteringSelect">
				<option value="de">germany</option>
				<option value="it">italy</option>
			</select> 
		</div>
	</div>
</form> 

</body>

Regards,

Florian

Change History (11)

comment:1 Changed 9 years ago by bill

Description: modified (diff)

Hi Florian,

Haven't tried your code but let me aska few questions:

Why does your dijit.form.Form have display:inline combined with width:100% and height:100%? Doesn't it need to be display:block?

In 1.6 dijit.form.Form has taken on some of ContentPane's behavior, specifically that when it has a single layout child, it tries to size the child to match it's own size. So, if you don't want that, if you want the BorderContainer to have it's own size, then you'd need to say doLayout=false on the dijit.form.Form. Which element did you want the size to be specified on, the Form or the BorderContainer?

comment:2 Changed 9 years ago by Florian

Hi Bill,

thanks for your answer. Originally I'd like the size to be specified by the BorderContainer? only, because in my understanding of a <form> it does not have any size/layout. It's only function is to enable contained inputs to be sent to the server.

Back to my example (I removed some of the needless styles from above - they came from tesing). Did you thought of something like this?

[...]
<form dojoType="dijit.form.Form" doLayout="false" style="height:100%;"> 
	<div dojoType="dijit.layout.BorderContainer" style="height:100%">
		<div dojoType="dijit.layout.ContentPane" region="top">
			title
		</div>
		<div dojoType="dijit.layout.ContentPane" region="center">
			Test-dijit.form.FilteringSelect: 
			<select dojoType="dijit.form.FilteringSelect">
				<option value="de">germany</option>
				<option value="it">italy</option>
			</select> 
		</div>
	</div>
</form> 
[...]

Same thing as before: It works for 1.6.0rc1 but not for 1.6.0. The title-pane is overlayed by the content.

Florian

comment:3 Changed 9 years ago by bill

Milestone: 1.61.6.1
Owner: set to bill
Status: newassigned

Oof, OK yes I see the problem, that's unfortunate. Yes, I was thinking of what you had above, except without any style on the <form> node. But like you said, that doesn't work.

This is all coming from the fix for #12097. Anyway, I'll check in a fix today, for trunk and the 1.6/ branch, will go into the 1.6.1 release.

comment:4 Changed 9 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [23961]) Fixes for regressions when dijit.form.Form is a top-level widget (i.e. not a child of a layout container) yet contains layout children.

Fixes #12372, refs #12097 !strict.

Fixes in trunk/ and on 1.6/ branch.

comment:5 Changed 9 years ago by bill

(In [23962]) Fixes for regressions when dijit.form.Form is a top-level widget (i.e. not a child of a layout container) yet contains layout children.

Fixes #12372, refs #12097 !strict.

Fixes in trunk/ and on 1.6/ branch.

comment:6 Changed 9 years ago by bill

(In [23963]) Fixes for regressions when dijit.form.Form is a top-level widget (i.e. not a child of a layout container) yet contains layout children.

Fixes #12372, refs #12097 !strict.

Fixes in 1.6/ branch (previous two checkins partially failed).

comment:7 Changed 9 years ago by Florian

Resolution: fixed
Status: closedreopened

Hi Bill,

sorry for reopening this ticket, but there is still something that is not working as in 1.6.0rc1: If you resize the window the BorderContainer? and Contentpanes within the Form do not resize accordingly but stay the same size they initially have been.

Regards,

Florian

comment:8 Changed 9 years ago by bill

Hmm, I see, fair enough, thanks for catching that. Actually I expect you'd have the same problem if you replaced the Form with a ContentPane, and further that the ContentPane --> BorderContainer problem presumably existed in 1.5 too... although that's admittedly an uncommon page layout.

comment:9 Changed 9 years ago by Florian

Hi Bill,

I'm not fixed on this particular 'uncommon' page-layout: If there are other possibilities to put a page layout with title-bar, content-area (and leading + trailing for my 'real' application) into one <form> they're welcome. The only reason why I use this form/page-layout is I did not find any other one fitting to this scenario. ;-)

Regards,

Florian

comment:10 Changed 9 years ago by bill

Florian, you misunderstood my comment.

comment:11 Changed 9 years ago by bill

Resolution: fixed
Status: reopenedclosed

(In [23984]) Account for browser resize events changing size of form, in which case form must notify children that their size changed. Fixes #12372 !strict.

Note: See TracTickets for help on using tickets.