MultiSelect, closeOnSelect:false - Jumps to top of list each selection

[zambodi]

When using a select with mode of multiple and closeOnSelect as false, the drop down jumps to the top of the list with each selection. This requires the user to scroll back down to where they were in the list to find the next selection. Search works well; however, you need to know what you're searching for. Sometimes, as a user, you don't know what choices your list contains.

Here is a jsFiddle:
http://jsfiddle.net/WP97R/1/

[zambodi]

Hey, I was able to fix this in the Select2.js file, so that when in the multi-select & closeOnSelect is false, it will stop selecting the first entry in the list. It's a small trivial fix, but eliminates a great amount of frustration. Thought I'd share:
Version: 3.4.1 >>> onSelect: Line: 2664 >>> postprocessResults(null, null, this.opts.closeOnSelect);

[ivaynberg]

thanks

[joelbrewer]

Hmm. I am still getting this issue in 3.5.1 -- It is very frustrating for my client to have to scroll back down to where they were after each selection.

[kevin-brown]

Reopening this pending further debugging.

[kevin-brown]

Confirmed as fixed in 3.5.2 again.

[BonDoQ]

This Bug is happening again with version 4.0.3

http://jsfiddle.net/BonDoQ/rzvemnqy/

Problem:
https://github.com/select2/select2/blob/master/src/js/select2/results.js#L279
It always highlight the firstSelectedItem / firstItem

Solution:
check this condition before trigger that function would prevent the behaviour for that case

if(!(self.options.get('multiple') && !self.options.get('closeOnSelect'))) {
  self.highlightFirstItem();
}

[NewLIST]

I solved this with the following:

var scrollTop;
$('#mySelect2').on("select2:selecting", function( event ){
    var $pr = $( '#'+event.params.args.data._resultId ).parent();
    scrollTop = $pr.prop('scrollTop');
});
$('#mySelect2').on("select2:select", function( event ){
    var $pr = $( '#'+event.params.data._resultId ).parent();
    $pr.prop('scrollTop', scrollTop );
});

Perhaps not the most elegant solution, but essentially we listen for the selecting event and then grab the current scrollTop of the selectable options panel. On the actual selection, we reset the panel's scrollTop back to its original. This happens so fast that you should see no jump in the control window. Only test with Select2 v. 4.x.

The nice thing about this solution is that you don't have to hack the component or include anything in your config functions.

[jackson-sandland]

I am able to resolve this locally by commenting out self.highlightFirstItem in the results.js file. However, this is not a great fix, because whenever the node_modules are installed the change will be overwritten. I suggest that this feature be set to a boolean, so that devs can easily turn it on or off. The list we are using for our clients is long, and jumping to the top of the list doesn't improve the UX. What is a better workaround? I've tried the DOM manipulation but haven't been able to lock it down. Thanks!

self.setClasses(); self.highlightFirstItem();

[publishest]

Could noy find a better way than this...

` var scrollTopSl2;

$(document).on('select2:selecting', 'select[multiple]', function(event){

scrollTopSl2 = $( '#'+event.params.args.data._resultId ).closest('#select2-'+event.target.id+'-results').prop('scrollTop');

});

$(document).on('select2:select', 'select[multiple]', function(event){

 $( '#'+event.params.data._resultId ).closest('#select2-'+event.target.id+'-results').prop('scrollTop', scrollTopSl2 );

});

$(document).on('select2:unselecting', 'select[multiple]', function(event){

scrollTopSl2 = $( '#'+event.params.args.data._resultId ).closest('#select2-'+event.target.id+'-results').prop('scrollTop')

});

$(document).on('select2:unselect', 'select[multiple]', function(event){

 $( '#'+event.params.data._resultId ).closest('#select2-'+event.target.id+'-results').prop('scrollTop', scrollTopSl2 );

}); `

[Ecksters]

Seems like this is happening in the current version.

[shawty]

plus 1 to that, happening for me too. Just done an NPM update to make sure I have the latest build (April 4th 2017) and still no diff.

[MicahBrown]

@jackson-sandland's solution worked for me as well. I also agree that it's poor UX behavior as I can't see any upsides to this behavior.

[emileindik]

Any progress on this issue? Was it ever corrected in master branch?
Thanks!

[shawty]

Doesn't appear so, for me, I just wrapped my selects in custom components and managed the datatype marshaling myself.

[MicahBrown]

@kevin-brown Can we get my #4869 PR merged so we can get a fix for this on master?

[joelworsham]

I'm eagerly awaiting as well, as I use the CDN hosted source, so I can't fix it. Thanks!

[alexweissman]

Reopening this issue, as apparently it is still happening in 4.0.x.

[alexweissman]

Actually, I am going to close this issue because there is a newer issue, #4417, which seems to have some insight as to what's causing this issue in 4.0.x.

[smalezan]

Find this part of the select2.min.js and delete it.

,f=this.$results.scrollTop()+(e-d),g=e-d;f-=2*a.outerHeight(!1),c<=2?this.$results.scrollTop(0):(g>this.$results.outerHeight()||g<0)&&this.$results.scrollTop(f)

It worked for me

[alexweissman]

Please continue discussion in #4417.