Input box for ui-select multiple ALWAYS forcing text entry at new line

[aronmgv]

Bug description:

Input box for ui-select multiple forcing text entry at new line, even if values do not take up entire first line

There is already closed issue for this #1556 undesired behavior.. but for older version. Since I got no help there, opening new issue.

Link to minimally-working plunker that reproduces the issue:

plunker
All selects forces new line when there is at least 1 item selected.. this was not happening before..

Notice also that only like 40% of the line is clickable in order to start typing in it:

Version of Angular, UI-Select, and Bootstrap/Select2/Selectize CSS

Angular: 1.6.4
UI-Select: ^0.19.8
Bootstrap/Select2/Selectize CSS (if applicable): ^3.3.7

[Jefiozie]

Hi,

Thanks for the issue, maybe you could have a look where the problem is coming from and make a PR?
Happy to review for you.

[frame]

I didn't find the actual cause yet, but it got introduced in 0.19.7. Reverting back to 0.19.5 fixes the issue.

Update: I believe I found the culprit: 7ad4ef1

[fosron]

+1

[aurelienlt]

Oh I haven't seen it was a recent issue, I commented the older one. Here is the fix I found.

In the code of the updateIfVisible function, it tries to make the input fit in the line using var inputWidth = containerWidth - input.offsetLeft.

updateIfVisible = function(containerWidth) {
  if (containerWidth === 0) {
    return false;
  }
  var inputWidth = containerWidth - input.offsetLeft;
  if (inputWidth < 50) inputWidth = containerWidth;
  ctrl.searchInput.css('width', inputWidth+'px');
  return true;
}

However it cannot be done since the input is already on the second line. By reducing the input first and enlarging it to the rest of the block, it works:

updateIfVisible = function(containerWidth) {
  if (containerWidth === 0) {
    return false;
  }
  ctrl.searchInput.css('width', '50px');
  setTimeout(function(){
    var inputWidth = Math.max(50, containerWidth - input.offsetLeft - 10);
    ctrl.searchInput.css('width', inputWidth+'px');
  }, 0);
  return true;
}

[mkeremguc]

also, there is a height problem for multiple. the input's height is shorter when it is empty, at least for bootstrap theme. you can compare multiple input's height with non-multiple

[giacomomasseron]

+1, same problem with chrome

[AbdallaElabd]

Changing this line https://github.com/angular-ui/ui-select/blob/master/dist/select.js#L839
from
var inputWidth = containerWidth - input.offsetLeft;
into
var inputWidth = containerWidth - angular.element(input).offset().left;
fixes it for me.

[ciaran-phillips]

As far as I can tell the root issue is that ui-select is relying on the element's clientWidth property when calculating the available area for the input. clientWidth includes the element's padding, so it overestimates the available area.

Previously, ui-select compensated by subtracting an extra 10px from the container width:

var inputWidth = containerWidth - input.offsetLeft - 10;

But that was removed in 7ad4ef1

Even if that was change was undone, I believe it would still break for anyone who wanted to set a larger custom padding on their element. I think the best solution is probably to take into account the actual computed padding values from window.getComputedStyle(element) when determining available area

[aurelienlt]

Finally got a clue why the "-10" was removed. In not multiple case, this -10 will shrink from 10 pixels the input (so visually, the whole select shrinks from 10 pixels).

I'm now using:

var inputWidth = containerWidth - input.offsetLeft - (ctrl.multiple ? 10 : 0);

[sonmezonur]

None of solutions actually fix the problem. I think the problem is much deeper since it does not provide enough flexibility. User should be able to access drop-down list by clicking ANY space on input box. If you decrease the input width as suggested, generally ends up with less interaction area even if it may not force text entry in new line.

[stephen-dahl]

I don't know what the browser support requirements are but this is an easy fix for flexbox (IE10+) the current structure for multi-select is (not exact names)

<div class="wrapper">
    <span>
        <span>first selection</span>
        ....
    </span>
    <input class="ui-select-search">
</wrapper div>

change it to

<div class="wrapper">
    <span>first selection</span>
    ....
    <input class="ui-select-search">
</wrapper div>

and give it the following css

.wrapper{
    display: flex;
    flex-wrap: wrap;
}
.ui-select-search{
    flex-grow: 1;
}

this will allow you to let css handle it automagically and not have js setting the width at all

I also agree with the statement above that clicking anywhere in the box should open the dropdown and focus the input

[andreiho]

I would also expect to be able to click anywhere in the box to search.

We can achieve this easily with basic HTML, without any complicated calculations. Just wrap ui-select-match and ui-select-search in a <label>:

<label>
  <span class="ui-select-match">
    ...
  </span>

  <input type="text" class="ui-select-search">
</label>

And add the following CSS to make it look like the whole thing is an input:

label {
  display: block;
  cursor: text;
}

PR: #2057

[parker789]

Can we get a fix for this merged? This really breaks the functionality of this library.

edit: I personally think that a combination of @andreiho and @abdallamohamed solutions should be merged.

[jfinckh]

Any Update on this?

[parker789]

I've come to the conclusion that this library is dead. Was good.. but now I feel that moving away is the best call for production level apps

[ChristianGruen]

If this library should be dead indeed, couldanyone recommend good alternatives?

[andreiho]

@ChristianGruen There aren't any good alternatives that can do everything this project can do. There are some simpler ones for doing tagging, such as angular-chips or ngTagsInput, but as you can see most of these projects aren't that active either.

[Pritraj]

yes #2125 is working for my case thanks @sunilkandakatla

[stephen-dahl]

Can this be closed? it has a merged pr and is very old.

[svpace]

AFAICT the bug is still there, at least for 0.19.8. I don't think PR #2125 have been merged yet.

…

On Fri, Aug 17, 2018, 11:10 Stephen Dahl ***@***.***> wrote: Can this be closed? it has a merged pr and is very old. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1980 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEKqyqJuzkkVGWQdmKw_-bp2YMmEPdwEks5uRs69gaJpZM4NDwag> .

[frame]

@stephen-dahl I just successfully tested PR #2125 on Chrome 68, Firefox 61 and IE 11 and it does fix the problem in my projects, but the PR hasn't been merged into master yet.