Opened 7 years ago
Closed 7 years ago
#17467 closed defect (invalid)
_HasDropDown & forceWidth:true, dropDown positioned incorrectly
Reported by: | Monty Dickerson | Owned by: | Monty Dickerson |
---|---|---|---|
Priority: | undecided | Milestone: | tbd |
Component: | Dijit | Version: | 1.9.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
With long/wide content in dropDown with forceWidth:true, the calculation for placement of the dropDown (dijit/popup) doesn't consider the forceWidth:true, so the position can be way off in some cases.
Adding this line to _HasDropDown::openDropDown() before popup.open() call is a workaround for this bug. It sets the dropDown's width to the aroundNode's width: so that when popup goes to place it, its calculations won't be based on the intrinsic width of the dropDown's lengthy content, but rather on the expected forced width.
if(this.forceWidth){ domStyle.set(ddNode, "width", aroundNode.offsetWidth + "px"); }
Attachments (1)
Change History (9)
comment:1 Changed 7 years ago by
Component: | Dijit - Form → Dijit |
---|---|
Owner: | set to Monty Dickerson |
Status: | new → pending |
comment:2 Changed 7 years ago by
Status: | pending → new |
---|
Note: this defect did not exist in earlier Dojo version 1.8.2.
comment:3 Changed 7 years ago by
Status: | new → pending |
---|
comment:4 Changed 7 years ago by
Status: | pending → new |
---|
Attachment (test17467.zip) added by ticket reporter.
Changed 7 years ago by
Attachment: | test17467.zip added |
---|
screen shots, test template, and patch for this
comment:5 Changed 7 years ago by
The forceWidth parameter's docuemntation says "Set to true to make the drop down exactly as wide as this widget." I hope that my understanding of this intent is good, and that the attached test case will illustrate what I'm seeing.
Using a dijit.form.Select widget, which _HasDropDown, I'm not seeing drop down exactly as wide as this widget. File test17467.zip has screen captures of the first and second openings of the dropdown on the select, in the given testTemplate.html.
Note the style block in the template: the application of table-layout: fixed (et. al.) is necessary to visualize the operation of forceWidth. Please advise if this functioning as designed, or a regression from v. 1.8.2.
It seems logical to me to apply the overflow: hidden and text-overflow: ellipsis styles to options of the select when the forceWidth is applied. If I'm understanding the intended use case for forceWidth.
Thanks for your clarification and help with this.
comment:6 Changed 7 years ago by
In the original report my focus was on the positioning. Pls disregard that: my main focus is on the width of the dropdown and the widget. If that is right, the placement will be, too - as you say!
comment:7 Changed 7 years ago by
Status: | new → pending |
---|
Thanks for the patch, but can you attach an actual test file? I looked in your zip and I see a template, but no actual test file that reproduces the problem.
comment:8 Changed 7 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
forceWidth just matches the dropdown's width to the anchor's width, so I don't see how there could be an issue unless the anchor node itself flowed off the screen. But please attach a test case so I can see what you are talking about.