Maintain multi select scroll position with hide_results_on_select = false

[kalebanderson]

I have a multi select that utilizes the hide_results_on_select = false feature, so it stays open when an option is selected. This is a nice feature addition, but I would also like the scroll position to be maintained, so that if you are clicking several items in a list, you don't need to scroll through the list after each selection to get back to where you were making selections.

Steps to reproduce

1. Initialize a Chosen multi select with hide_results_on_select = false. The select should have many options (to force scrolling).

2. Open the select dropdown and scroll to an item near the bottom of the list. Select that item.

3. Observe that the menu stays open, but it jumps to the top of the options list.

Here is a Fiddle I created that shows the issue.

Expected behavior

I think it makes more sense for the scroll pane viewable area to not change and remain on the option that was selected. There does not appear to be any benefit to shifting to the top of the menu.

Actual behavior

Scroll position is not maintained in the scroll pane.

Environment

• Chosen 1.8.2

• Tested with jQuery 2.1, 3.2 (assumed to affect all versions of jQuery)

• Tested with Chrome 62, IE 11, Firefox 56 (assumed to affect all browsers and versions)

• Tested with Windows 10 (assumed to affect all OS)

Additional information

I am willing to work on a pull request for this issue if the change will be incorporated into the plugin. I'd like to avoid maintaining a personal fork of the plugin.

[hereswhatidid]

Can you post your fix here? I'm experiencing the same issue.

[kalebanderson]

I haven't written a fix yet, as the issue hasn't been a showstopper for me, just an inconvenience. I really prefer not to maintain my own version of the project, so I was hoping for a response from the original author.

[solsticesurfer]

The culprit here is found in winnow_results_set_highlight() at line 1246. It's purposefully jumping to the top of the list. Not sure what the intent with this section is (and it's late) but I don't want to comment it out completely. The quick fix for the time being is to put a test around the call to result_do_highlight at line 1248 that checks to see if the list is a multiple select.

So, line 1247 becomes
+ if(!this.is_multiple) {
and line 1250 becomes
+ }
to close the test.

Note: the source file here is generated JavaScript file. I'll modify the coffeescript file once I know this fix is correct.

I'll be testing this change tomorrow but, if anyone has already gone through this and has some insights to share in the meantime, it would be appreciated.

[kalebanderson]

@solsticesurfer your change does appear to work! I don't know anything about the original intent of the way the feature worked, but I think this would be a step in the right direction.

[Wizard13]

I have downgraded to v1.7.0 because of this (however display_selected_options: false doesn't work with it). This regression first appeared in v1.8.0

[frontend-dude]

Anyone found a solution for this?
It's kind of annoying because the concept of "multi" select is actually selecting more than 1 item, so why should it scroll up again?!

[kalebanderson]

@ArashFrontend follow solsticesurfer's fix above for now. Hopefully that change or similar can be merged into a release eventually.

[dvtan]

I was deciding between chosen and select2, and fortunately select2 doesn't have this issue. I am currently using select2 now.

[Wizard13]

Isn't this going to be fixed?