Opened 6 years ago

Closed 6 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)

test17467.zip (15.6 KB) - added by Monty Dickerson 6 years ago.
screen shots, test template, and patch for this

Download all attachments as: .zip

Change History (9)

comment:1 Changed 6 years ago by bill

Component: Dijit - FormDijit
Owner: set to Monty Dickerson
Status: newpending

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.

comment:2 Changed 6 years ago by Monty Dickerson

Status: pendingnew

Note: this defect did not exist in earlier Dojo version 1.8.2.

comment:3 Changed 6 years ago by bill

Status: newpending

comment:4 Changed 6 years ago by Monty Dickerson

Status: pendingnew

Attachment (test17467.zip) added by ticket reporter.

Changed 6 years ago by Monty Dickerson

Attachment: test17467.zip added

screen shots, test template, and patch for this

comment:5 Changed 6 years ago by Monty Dickerson

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 6 years ago by Monty Dickerson

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 6 years ago by bill

Status: newpending

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 6 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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!

Note: See TracTickets for help on using tickets.