ZalemCitizen
commented
11 years ago Well, the problem is simple in fact.
Select2 is divided in 2 parts:
- select2-container is placed right next to original select (or hidden input when working with dynamically loaded data)
- select2-drop is placed just before /BODY tag (note that this element is unique and is used for each one of your select2 when you open it) The input field .select2-input, child of select2-drop.
BlockUI, by default, disables key and mouse event for elements not located in its message, just as said by you, malsup, in the documentation:
// enable if you want key and mouse events to be disabled for content that is blocked bindEvents: true,
So, when you initialize a select2 on a field located inside a blockUI message, everything's alright except that key and mouse events are disabled in the input.select2-input field which is not inside the blockUI message but way outside near the end of your document html...
the solution is as simple as this: init your blockUI with option :
bindEvents: false,Beware of elements that could keep or take the focus outside of blockUI elements then, because mouse and key events would not be neutralized.
Maybe a little improvement specific to select2 architecture inside blockUI can be found to make it cleaner.
I load select2 in a tooltip (qtip2) that opens when an event contained in a jquery.fullCalendar is clicked. The fullCalendar is itself displayed in a div, used as blockUI message that overlays my application.
Natively, the search field of select does not work properly. With jquery blockUI version 2.57.0 (17.02.2013) I can make the search field of select2 work as expected by blocking an element in the background application and unblocking it right away:
$("#someDivInTheBg").block(); $("#someDivInTheBg").unblock();
Curiously, that workaround does no longer works with jquery BlockUI version 2.64.0 (18.07.13). I can't figure what's going on, and I could find how to track the issue except that it's obviously in blockUI/select2 interaction.
Note that sometimes, when I try to use the select2 search field right after he's displayed, the first char I enter is displayed in the search field before it's locked. Since there's no blockUI loading when I open the qtip, the issue may be triggered by select2 code.
Note also that the problem does not occur with another select2, located in the background application (not inside the blockUI message)
I'll try to report the problem in blockUI and select2 githubs
This issue was first reported here: http://stackoverflow.com/questions/14957771/select2-search-not-working/18405322