Scroll back to the input field when lost focus (after select2:closing)

[roman4e]

Prerequisites

• I have searched for similar issues in both open and closed tickets and cannot find a duplicate
• The issue still exists against the latest master branch of Select2
• This is not a usage question (Those should be directed to the community)
• I have attempted to find the simplest possible steps to reproduce the issue

Steps to reproduce the issue

There is jsfiddle with complete example page: https://jsfiddle.net/1hw1250x/

1. Open fiddle link
2. Click on select2 field. It should open with suggestions. Do NOT select anything
3. Scroll down to the gray square
4. Click on the square

Expected behavior and actual behavior

When I follow those steps, I see the page is scrolled to the top (where select2 element is present)

I was expecting not to scroll and still see gray square

Environment

Browsers

• Google Chrome
• Mozilla Firefox
• Internet Explorer

Operating System

• Windows
• Mac OS X
• Linux

Libraries

• jQuery version: 2.2.4
• Select2 version: 4.0.3

Isolating the problem

• The bug happens consistently across all tested browsers
• This bug happens when using Select2 without other plugins
• I can reproduce this bug in a jsfiddle

[zoka123]

+1

This is really bad UX. If user scrolls and place his focus inside other form field, the screen will be scrolled back where select2 element is.

Commenting out this line

select2/dist/js/select2.full.js

Line 1407 in 04d5821

self.$selection.focus();

resolves this issue, I'm not sure why is this added? Is it necessary for something else?

[alexweissman]

I can reproduce this behavior. I'm kind of confused though, because #4971 seems to be saying the exact opposite thing.

[jpic]

I feel pretty confident that it should not auto-focus after programatic deselect: if the developer wants to deselect and focus back then I feel they should call both in a row.
@alexweissman it's not the same issue, in #4971 focus is lost after selecting an option which breaks tab navigation. Here, focus is taken after selecting an option programaticaly.
So, to answer @zoka123 I think yes, this /might/ be the reason why it's here, in which case this confirms your hypothesis.
Now, are many bugs are there exactly, how should the spec be, how should the code be, are all open questions, and it looks like a refactor might be necessary to support these "contradictory" (in terms of code, but not in terms of user story) specs.

[alexweissman]

I have confirmed that this issue is still present in 4.0.4.

[alexweissman]

You'll notice that PR #4860 and #3394 actually wrap self.$selection.focus(); in a setTimeout block...interesting.

[alexweissman]

This actually appears to be a duplicate of #3663.