-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
Bug: Open dropdown list snaps back to top if first several options are disabled when hovering over first enabled option #1879
Comments
I am also having this issue. Here is the JSFiddle: http://jsfiddle.net/derekvasilich/gefBD/ Any idea if/when this will be resolved? Or is there a workaround? |
@derekvasilich It doesn't appear as though a workaround has been found, though if you are able to find one (or a fix), feel free to make a pull request/comment about it. This may be related to #2038, considering they both seem to have the same problem (just different setups). |
Same bug as in #2189 |
I have the same issue. This is introduced by this commit: Apparently to fix keyboard navigation. While keyboard navigation works better with the changes, it's still not bulletproof. When all the options you can see with the scrollbar on top are disabled and you navigate with your keyboard to the first enabled option, it also jumps to the top. The result here is that you cannot see your selected item. Lacking a better solution I chose to turn off this behavior for now. |
As a workaround for this issue, I removed the code I'm thinking that it is a start point to fix this issue. Maybe inside this function the code maybe may determine if the first option is preceded by disabled options. |
Has this issue been resolved yet? |
@shavo007 Should be fixed in 4.0 as we no longer "guess" where the highlight should be. |
Cheers for the reply. 4.0 milestone is targeted for Jan 2015 Kevin? |
See this solution. It works without hacking the control. |
Is anyone still seeing the bug in 4.0.3? I am getting it with a multiple selection. var scrollTop;
this.selectElement.on("select2:selecting select2:unselecting", (event: any) => {
if (event.params.args.originalEvent) {
scrollTop = $(event.params.args.originalEvent.delegateTarget)
.prop('scrollTop');
}
}).on("select2:select select2:unselect", (event: any) => {
if (event.params.originalEvent) {
$(event.params.originalEvent.delegateTarget)
.prop('scrollTop', scrollTop);
}
}); |
I'm not seeing this specific bug, but I am seeing a similar thing. If I have a select with objects say:
And a local class property say
When the form loads, it will show "Paul" in the drop down, but as soon as I change it, the bound value in the select value changes to the correctly selected value, but the text in the drop down snaps back to the first in the list "Peter" adding a text box above the select and binding it to the same value as the select shows that the value in there persists correctly EG: 2 if I select john, but the select will always show "Peter", this also works the other way too. If I change the value in the text box, the value changes but the select stays stuck on the first item in the list. |
Steps to reproduce:
Expected behavior:
Actual behavior:
Here's a jsfiddle demonstrating the problem: http://jsfiddle.net/7JaZb/
It's a little tricky to reproduce, so if you need a screencast or more details, please let me know.
This doesn't appear to happen if the first option is enabled, even if enough subsequent options are disabled to push the rest of the enabled options off the bottom of the visible part of the list when it's initially opened.
Only hovering over the very first enabled option causes this to happen. Scrolling down the list using the scrollbar, then moving your mouse up from the bottom of the list, works OK until you hit the topmost enabled option.
The net result is that it's not possible to select the topmost enabled option with the mouse when this happens. You can still get to it by typing to filter the list, so you're not totally blocked, but it's close.
The text was updated successfully, but these errors were encountered: