multiselect button & widget width is not properly calculated in some situations

[Lukapt]

Hi,

First of all, congratulations for the widget.

Problem 1:
I'm not absolutely sure this is a multiselect issue/responsibility or just a consequence of jQuery element width calculation.

The problem is that the multiselect width is not being properly calculated when using a select element with width = 100% inside a table.

As I understood while debugging this is because the select element width is different when the element is hidden. In fact this is well documented in http://api.jquery.com/outerwidth/

The value reported by .outerWidth() is not guaranteed to be accurate when the element or its parent is hidden. To get an accurate value, ensure the element is visible before using .outerWidth() (...)

From the multiselect widget perspective it would not make sense to just hide the source select element when the width was calculated to avoid this behavior?

Here is the jsfiddle: https://jsfiddle.net/dr7d7h84/

---

Problem 2:
Additionally I don't think that the widget width is being properly calculated even for "normal" scenarios. Again, I think this might be a jQuery problem (please see jquery/jquery#1712).

Here is the jsfiddle for this scenario: https://jsfiddle.net/ccbe87qa/

As you can see the widget button width is not the same has the original select width. Is this the expected behavior?

Thanks

[mlh758]

What version of the widget are you using for these? Two of the fixes in the 1.14 change log are:

Fixed: get appropriate width before hiding original element. (#609, #614)
Fixed: get appropriate width when source element is styled to 100% (#546)

[Lukapt]

Oh, I see. I'm using 1.13.
I was not aware of the new version. Sorry about that. I will update the version.

Thanks

[mlh758]

I'll leave this open until you get a chance to see if things are working for you. My tests are passing, and a couple other users have reported this as fixing the problem for them but that's not a particularly large set of test cases.

[Lukapt]

As you said the 1.14 version pretty much solves both problems.

However I'm still having problems when using width=100% in the table.

Here is the fiddle: https://jsfiddle.net/dr7d7h84/3/

It seems that this happens because the column width is automatically recalculated by the browser when the first multiselect is applied. Consequently the width of the remaining select elements is changed.

[mlh758]

I tried shortening up some of the text in the options and it gets even more unusual.

https://jsfiddle.net/dr7d7h84/7/

Some of the multiselects shrink up and others don't.

[Lukapt]

Has you can see in the console logs the column width keeps growing.
https://jsfiddle.net/dr7d7h84/8/

This happens when the table width is 100% and the element width that is inside the td don't have width 100% anymore. By applying a fixed value the column width changes.

[mlh758]

What would be the expected outcome here? When I resize the view section for the output the widgets consume up to 100% of the width after hitting run again. It almost seems strange that the widgets shrink when the options are shorter since they should be at 100%. The growing also seems problematic but the aren't overflowing off the side of the column either.

I can start working on a fix soon, but I'm not really sure what this should actually look like.

[Lukapt]

What I would expect is that all width remain the same as if no multiselect widget was applied since the multiselect widget is simply replacing the select element.

Here is a simple scenario:
https://jsfiddle.net/dr7d7h84/9/

However I'm not sure how this could be accomplished.

[mlh758]

Yeah they should at least be consistent within the column. I'll take a look over the next few days and see what I can come up with.

[Lukapt]

Thanks :)

[mlh758]

@Lukapt I finally got back around to this. Looks like the issue is you need to set some kind of width to the column the selects are in. I gave column 4 a width of 40% in your example and it worked.

https://jsfiddle.net/dr7d7h84/20/