New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Focus is lost while entering tags in Internet Explorer (IE11) #4398
Comments
This sounds like either it might be a regression or nobody has noticed it in the last year. Would it be possible for you to test if this issue exists in 4.0.0 - 4.0.2 as well? If it's a regression, it should be considerably easier to fix than if this issue has always existed. |
Good idea, I just checked and it worked all the way up to 4.0.2-rc.1, 4.0.3 is the first tag where the problem occurs. Actually I just bisected the issue and it turns out the following commit introduced the problem: ea79a19. The commit is not very long, hopefully you can quickly see what goes wrong. Thanks for your help! |
fixed after re-focus input |
We have seen this problem in IE 11 also. A fix for this would be hugely appreciated. |
We pulled the parent of the hash mentioned by luetge above and haven't had any problems thus far. We'll probably go with that unless we run into a problem. |
Confirmed - reverting to 4.0.2-rc.1 fixed this issue for me. And even more importantly, it solved an issue on chrome on iOS that behaved exactly like the IE issue. Enter one or two chars - focus shifts away. All good now. |
Confirmed—reverting to |
Any word on when this can be added to the timeline for fixes? |
Any glance of when we can expect fix for this to be live?? I have same issue occurring in IE11 |
Reverting to |
I am not so fortunate. If I try to add a new tag: "k1234567", in 4.0.3 and 4.0.2, I get only "k1". In 4.0.2-rc.1 and 4.0.1, I get "k1357". Is there any hope for a live fix for this? |
Is this still an issue on IE 11 and the master branch version ? |
Absolutely. As to today (1/30/2017)
…On Mon, Jan 30, 2017 at 7:04 PM, James Pic ***@***.***> wrote:
Is this still an issue on IE 11 and the master branch version ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4398 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA3nbweBqJTjdn9TxfRua2YldwSxQLRmks5rXnqRgaJpZM4ItCHd>
.
|
Great, is a patch submitted already ?
|
I don't know about a patch, and really don't have expertise to do this
myself. I have been using select2 for a while, on Chrome and it works
fine. Now, my users are complaining it does not work on Internet Explorer,
which was a surprise to me. Now, I am stuck, since tagging has to work on
ie. I verified that if I have to add a tag in IE like k1234567, the 4.0.3
version takes k1, and then I can't type more. Earlier versions (e.g 4.0.1)
take k1357, which is obviously unacceptable. I don't know how to proceed,
other than to stop using select2, which I prefer not to do.....
…On Tue, Jan 31, 2017 at 3:17 AM, James Pic ***@***.***> wrote:
Great, is a patch submitted already ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4398 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA3nb9XnR6Ilb12f5IQw6t6naadAuUovks5rXu4ugaJpZM4ItCHd>
.
|
Ok then, are you able to find the exact commit that introduced the issue ?
That would help **a lot** to make a patch.
|
If I read the commit history correctly, ea79a19 is part of 4.0.3, but I am
having problems with 4.0.1, and possibly before.... There might be more
than one bug in here?
…On Tue, Jan 31, 2017 at 8:29 AM, Robin Sue ***@***.***> wrote:
As pointed out by @luetge <https://github.com/luetge> it was ea79a19
<ea79a19>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4398 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA3nb8V4xYZYzbuUDLXEriay0wsr5BAqks5rXzcogaJpZM4ItCHd>
.
|
Same issue in IE11 for me, I found this when evaluating Select2 on the demo page https://select2.github.io/examples.html#tags I type 1 letter and it stops. |
Ok, it would help if we know what in the patch exactly broke support for ie11, then someone could propose a patch ! |
I have resolved this problem in the Select2 source. The issue is that IE 11 needs a little extra help re-focusing the search input. The fix is to call $search.focus() (from search.js - Search.prototype.update function) in a timeout, fixed code below: Search.prototype.update = function (decorated, data) {
var searchHadFocus = this.$search[0] == document.activeElement;
this.$search.attr('placeholder', '');
decorated.call(this, data);
this.$selection.find('.select2-selection__rendered')
.append(this.$searchContainer);
this.resizeSearch();
if (searchHadFocus) {
var self = this;
window.setTimeout(function() {
self.$search.focus();
}, 0);
}
}; |
I tried to submit a PR but did not have the correct permissions. You may want to wrap the setTimeout logic in a separate function (reallyFocus, :)) as it appears to be used in other places. |
FYI, this also required a minor change to the test case search.tests.js - test('updating selection does not shift the focus': ...
setTimeout(function() {
assert.equal(
document.activeElement,
$search[0],
'The search did not have focus after the selection was updated'
);
}, 0);
... |
One of our users also reported this issue. Thank you for your work. |
Tagging focus issue still persist in IE11 with 4.0.6-rc.1 version. I have tried running select2 example page on IE11 and not able to type after 2 characters. |
Ah, let me update the example page to use the new version. Stand by. |
I've pulled 4.0.6-rc.1 and have confirmed that, while it does contain the pull-request that is said to fix the issue, that the problem still exists in IE11. The symptoms are exactly as described in the original comment. |
The PR with the supposed fix does not fix the issue. The focus call needs to be made in a timeout: |
Anyway, I have updated the live docs to use the latest version (4.0.6-rc.1), and the focus issue seems to be resolved in IE11. That being said, I do notice a number of other problems in IE11, but those are under discussion in other issues. |
Generally, yes. However, a setTimeout call with 0 does serve a purpose. https://stackoverflow.com/questions/779379/why-is-settimeoutfn-0-sometimes-useful. |
Very interesting, thanks for sharing. Anyway, if you think this bug is still not entirely fixed, let us continue the discussion in the PR itself (#4860). |
Please take a look at #5161. |
This issue still seems to be in the code base, and the PR #5161 was closed without merging due to files in the dist folder. I have pinned my work to 4.0.2 which seems to not have the issue (as per the comments above), but will this be fixed in a new version? I'd be happy to submit a PR with the changes from #5161, but the code would not be mine! |
I am using |
4.0.7 and I can reproduce this issue in Chrome and Safari on OSX. |
I think this may have been fixed in Select2 4.0.8 when correcting a different focus issue. |
I can reproduce the issue in Chrome 75 with Select2 4.0.8 When I type 2 characters focus for the input is lost, but it would appear the full drop-down list has focus, including any results that have been filtered out by the input. This can be seen by typing 2 characters that visibly filter the list then using the up/down arrow keys which then scrolls through the options in the drop-down menu. This scrolling in turn removes all previously selected options replacing them with the option that is currently highlighted by the arrow keys. Also it would appear that changing application (alt+tab) from chrome then back gives focus to the correct input allowing you to type more a single char at a time... Apologies these descriptions aren't very technical, but I haven't seen this behaviour mentioned elsewhere.
|
I'm going to need a jsbin, jsfiddle, or other isolated reproducible test case where I can actually see this bug happening. Especially since it cannot be reproduced on the documentation website, that suggests that there is some other issue at play here.
Select2 4.0.8 is currently deployed to the documentation site, because that is the latest version of Select2. |
I'll check which version I'm getting when I use yarn to update select2, I made a jsbin here: https://jsbin.com/coliyuzulo/edit?html,output But version 4.0.8 works as expected... I think I just realised the issue, I'm using a template and it doesn't use certain packages from node_modules... So while I updated it correctly webpack never even saw that version... Confirmed, updated the random version in a vendor folder and it works perfectly... That's 4 hours I'm not gonna get back. Thanks for your reply though, once you mentioned it was the latest version on the docs I knew it had to be something I was doing wrong.. |
This issue is still happening in 4.0.8. Works fine in Chrome, not usable in IE11.
I noticed that this mostly happens after the second char, sometimes after the first and - if you type very fast or paste something - even later (as shown in the video below). Here is a video demonstration: I have a very minimal jsfiddle reprocuding the problem here: https://jsfiddle.net/8p1wyjvg/7/ This happens on select2 versions 4.0.3, 4.0.4, 4.0.5, 4.0.6 and 4.0.8. It does not happen in 4.0.7 though, at least in the example. In the real world application I use select2 in ist still happens in 4.0.7 (still have to figure out in which exact circumstances..) I "fixed" it by going back to 4.0.2 for now, but would really appreciate a long term solution. |
We are seeing this same behavior exactly as described by @eikowagenknecht in an application that uses select2 version 4.0.5. We looked back through this thread and attempted resolving the loss of focus using the fix described by @dmarginian with some success. With that fix in place, the focus was not lost as you typed past the 2nd letter in Internet Explorer 11 and the multi select continued to work as expected in latest versions of Edge, Chrome, Safari and Firefox. However, when we tried testing on an Android device running the latest version of Chrome we noticed that the keyboard came on and off the screen with each character typed rather than staying on screen the whole time as it did prior to applying the fix (The same behavior was also observed in the default Samsung Internet browser on the device. Update: On iOS Safari the fix causes the browser to lose focus after the second letter is typed just like the original problem in IE11). In my mind this makes the fix unusable since it significantly degrades the user experience for a larger set of users in order to fix the UI for a smaller set of users. It would still be great to find a solution that at least allowed IE users to use the multiple select without having to downgrade to 4.0.2. One option that would achieve this is if there was a way to prevent the user's input from clearing when they click back on their entered text in an attempt to regain focus. Edit: I tried the Tagging with multi-value select boxes example on the documentation site using IE11 and experienced the same loss of focus behavior. |
Currently experiencing the issue in IE on version 4.0.12, exactly as described in the above responses. |
Issue still occurs on IE 11 on the example page https://select2.org/tagging#tagging-with-multi-value-select-boxes when entering a second letter in the searchbox! |
I encountered the same problem in version 4.1.0 |
This issue should be fixed in the upcoming 4.1.0-beta.1 release of Select2. |
I'm still experiencing the same problem with IE 11 on Windows 10 (build 2004) using Select2 4.1.0-beta.1 |
Prerequisites
master
branch of Select2Steps to reproduce the issue
Expected behavior and actual behavior
When I follow those steps, the search field loses focus during waiting, typing has no effect, when clicking on the text to restore focus the text disappears. This completely prevents tagging functionality in this browser. FF&Chrome&Safari work.
I was expecting to be able to use tagging.
Environment
Browsers
Operating System
Libraries
Isolating the problem
The text was updated successfully, but these errors were encountered: