Opened 10 years ago
Closed 10 years ago
#14822 closed defect (fixed)
IE7+ - Indefinite resizing when 1 layout widget + non-layout widget put in dijit.form.Form
Reported by: | Evan | Owned by: | bill |
---|---|---|---|
Priority: | undecided | Milestone: | 1.8 |
Component: | Dijit | Version: | 1.7.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
When there are 1 layout widget 1 non-layout widget(or dom node) put under form, any resizing action will cause an indefinite resizing in IE7/8/9
Steps to see the issue:
- Running the attached test case in IE7+
- Resize the window
- The Title Pane is kept reszing and push the textbox downward indefinitely
Some observations:
dijit.form.Form inhereits from dijit.layout._ContentPaneResizeMixin which has an "doLayout" attr default is true, so if we have 1 layout widget 1 non-layout widget(or dom node) put in a form, when resizing action occur, form will think it has single child(by '_checkIfSingleChild()') and resize the child which results in the size change of the parent Form, then a deadlock occur.
There are 2 possible ways:
- In that case, doLayout should be false
- Form should not resize its child to fit the parent when there are more than 2 direct dom children of Form
But actually #1
and #2
have the same result => don't resize child anyway.
Attachments (1)
Change History (6)
Changed 10 years ago by
comment:1 follow-up: 3 Changed 10 years ago by
Component: | Dijit - Form → Dijit |
---|---|
Description: | modified (diff) |
Owner: | changed from Douglas Hays to bill |
Status: | new → assigned |
Hmm, I don't understand why this would happen when the _ContentPaneResizeMixin has this checking code:
// all child nodes are widgets childNodes.length == childWidgetNodes.length && // all but one are invisible (like dojo.data) candidateWidgets.length == 1
In any case, sounds like my bug though. (Maybe I missed something, but it also sounds like it's unrelated for Form and would probably happen with a plain ContentPane.)
comment:2 follow-up: 4 Changed 10 years ago by
Milestone: | tbd → 1.8 |
---|
OK, looks like candidateWidgets[] isn't what I want it to be. It's excluding TextBox. I only want to exclude non-visual widgets like ItemFileReadStore. The current logic is:
candidateWidgets = array.filter(childWidgetNodes.map(registry.byNode), function(widget){ return widget && widget.domNode && widget.resize; });
It's been that way since [15039], strange that we haven't seen this before.
PS: the workaround is to just set doLayout=false on your Form.
comment:3 Changed 10 years ago by
Replying to bill:
Hmm, I don't understand why this would happen when the _ContentPaneResizeMixin has this checking code:
// all child nodes are widgets childNodes.length == childWidgetNodes.length && // all but one are invisible (like dojo.data) candidateWidgets.length == 1In any case, sounds like my bug though. (Maybe I missed something, but it also sounds like it's unrelated for Form and would probably happen with a plain ContentPane.)
I think the root cause is though we have two widgets in the form, but only 1(TitlePane?) has resize(), so candidateWidgets.length == 1 and then this._singleChild = candidateWidgets[0]; Form will invoke titlePane.resize() which makes it fit to form whose resizse() is invoked --> then a deadlock occurs.
comment:4 Changed 10 years ago by
Replying to bill:
OK, looks like candidateWidgets[] isn't what I want it to be. It's excluding TextBox. I only want to exclude non-visual widgets like ItemFileReadStore. The current logic is:
candidateWidgets = array.filter(childWidgetNodes.map(registry.byNode), function(widget){ return widget && widget.domNode && widget.resize; });It's been that way since [15039], strange that we haven't seen this before.
PS: the workaround is to just set doLayout=false on your Form.
Yep, thanks, I was suggesting folks using that workaround
test case to reproduce the error