Opened 10 years ago

Closed 9 years ago

#15140 closed defect (fixed)

[patch] [cla] _HasDropDown miscalculates width of dropdown

Reported by: Douglas Hays Owned by: bill
Priority: high Milestone: 1.9
Component: Dijit Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:


Run test_Select.html on Chrome and open the "Test One" dropdown. You'll see whitespace to the right of every menu item. Close the dropdown and then reopen it. Now the whitespace is gone. _HasDropDown is changing overflowY AFTER calculating the width which changes the width for subsequent calculations.

Attachments (2)

15140.patch (382 bytes) - added by Douglas Hays 10 years ago.
possible fix
Screen Shot 2013-02-27 at 8.37.38 AM.gif (17.4 KB) - added by bill 9 years ago.
on my chrome/mac

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by Douglas Hays

Attachment: 15140.patch added

possible fix

comment:1 Changed 10 years ago by Douglas Hays

Owner: set to bill
Status: newassigned

comment:2 Changed 9 years ago by bill

Priority: undecidedhigh

comment:3 Changed 9 years ago by bill

Milestone: tbd1.9

comment:4 Changed 9 years ago by bill

Owner: changed from bill to Douglas Hays
Status: assignedpending
Summary: _HasDropDown miscalculates width of dropdown[patch] [cla] _HasDropDown miscalculates width of dropdown

Hmm I'm not seeing it on, are you? Testing on the latest chrome on mac.

I'm not sure if you are talking about space before or after the right border, but I'm not seeing either.

comment:5 Changed 9 years ago by Douglas Hays

Status: pendingopen

This is recreating for me using the 1.8.0 link you provided, as well as on trunk, using both Chrome/Win7 and Chrome/OSX. The extra space is from the end of the option text to the right border. The option "Washington" is the longest and thus the right border should be just after the end of the text. But the first dropdown open shows whitespace after the text, and subsequent opens have no additional whitespace.

Changed 9 years ago by bill

on my chrome/mac

comment:6 Changed 9 years ago by bill

I reproduced it on chrome/win7, and your patch seems to fix it, although it seems like a chrome (or webkit) bug that you are working around.

For the test case you listed (first Select in test_Select.html), for some reason on Chrome, initially the drop down's offsetWidth is 89px, rather than 72px. Although the "developer tools" (chrome's built in debugging tools) correctly show the dropdown's metrics as 70px content box + 2px border, offsetWidth is strangely 89px. Then, due to an arguable bug, _HasDropDown calls dropDown.resize({w: 89}), which does = "100%", which has the side effect of curing the original mismeasurement.

comment:7 Changed 9 years ago by bill

Owner: changed from Douglas Hays to bill
Status: openassigned

The strange initial offsetWidth comes from some strange CSS setting overflowX and overflowY on the Select menu, starting in [21699] (my check in). It looks like your patch to _HasDropDown worked because it nullified that CSS setting, so I can fix the problem by just removing that CSS.

There's another problem when a vertical scrollbar causes a horizontal scrollbar to appear too, like the maxHeight=200 example in test_Select, so that requires another fix.

Anyway, I will check in a fix, please test it too to see if I broke something.

Last edited 9 years ago by bill (previous) (diff)

comment:8 Changed 9 years ago by bill

Resolution: fixed
Status: assignedclosed

In [30698]:

Remove overflow CSS settings on SelectMenu which cause chrome to report the wrong offsetWidth. Also update _HasDropDown to not set the width or height of the dropdown except when necessary. Fixes #15140 !strict.

Note: See TracTickets for help on using tickets.