_HasDropDown forceWidth/autoWidth does not work reliably

[AJ Shankar]

When dropdown selections are very long, incorrect behavior results.

Say your ComboBox? is at x: 500px and is 100px wide, on a 600px wide viewport. Say also that the autocomplete results are very wide, so that the natural width of the autocomplete popup is 400px.

What should happen width forceWidth=true: The autocomplete popup is placed at x: 500px and is 100px wide.

What does happen: The popup is first displayed "around" the ComboBox?. Because left-aligning the popup with the left edge of the ComboBox? would put part of the popup off the right part of the viewport (since 500px + 400px > 600px), popup.js moves it left so that it is right-aligned with the right edge of the ComboBox?. Thus, its x-offset is 200px.

Then, _HasDropDown applies forceWidth. Since the dropdown is naturally 400px wide, it gets styled down to 100px wide.

The end result is that the ComboBox? is at x: 500px and is 100px wide, and the dropdown that's supposed to be right below it is at x: 200px and 100px wide. See screenshot for an example.

A correct solution would style the width of the autocomplete popup before the call to popup.open.

Currently, the width is computed assuming that the popup already exists. You could probably use the maxWidth and minWidth styles to avoid having to know the actual width of the popupWrapper.

A quick workaround is to call openDropDown() a second time after the first time it's invoked; at this point, the popup is already styled to the proper width, and popup.js will place it appropriately. However, this is not at all obvious from the observed behavior and I'd hate for other people to have to go through the debugging process I did to figure that out.

[AJ Shankar]

Screenshot of poorly placed autocomplete popup due to described issue.

[bill]

A correct solution would style the width of the autocomplete popup before the call to popup.open.

I see what you are saying, and actually it used to work that way but I changed it in 4d1ddb9 for some reason. I'll have to dig into it to remember why.

If we are lucky it's it can be fixed (as you said) by simply swapping the order of the popup.open() call and the width-adjustment code. But I'm guessing it's not that simple.

[AJ Shankar]

Yes, it's not exactly that simple, as the resizing code uses the popupwrapper dimensions, because there might be a scroll bar.

Another solution could be to change the popup.open call to take a desired width (or minWidth).

A simpler hack would be to just call popup.open() again after the resizing occurs.

[bill]

Duplicate of #17744.
OK, I believe this was already fixed in 0984b1ee62a6659b3f9013a34f16357cf8cabb99. Let me know if I'm wrong.

Although #17744 concentrated on RTL mode, it covers the case you described too.