Dialog: modal prevents focusing on absolutely positioned elements

Just to note, a more hackish but apparently better temporary workaround which avoids the whole if ( !$.ui.dialog.overlayInstances ) block to don't have to remove handlers after they're attached (bin):

(function() {
    var uiDialog = $.ui.dialog,
        dialogProto = uiDialog.prototype,
        createOverlaybk = dialogProto._createOverlay;
    dialogProto._createOverlay = function() {
        uiDialog.overlayInstances++;
        createOverlaybk.apply(this, arguments);
        uiDialog.overlayInstances--;
    };
}());

This has nothing to do with absolute positioning. You can't focus it because that element is not inside the dialog, it's a direct child of the body.

Select2 should either provide a way to append to a different element (preferably adopting our .ui-front logic) or you'll need to register the Select2 element as described in #9087.

Thanks for the reply @scott.gonzalez.

Now that I get to think about it a bit more, I believe Select2 has such an option. Unfortunately is not ideal for my use case which has way too many Select2 instances which can also change context (position in the DOM tree) dynamically.

Though the _allowInteraction() seems to be the way to go, I'll override it adding the .select2-drop selector to it. Thanks.

(Also, I meant absolute position in the sense of if said element was in the page flow, the element wouldn't "appear to be inside" the modal. But I admit that I expressed it badly, the title should've been "Dialog: modal prevents focusing on elements outside of the dialog container")

the title should've been "Dialog: modal prevents focusing on elements outside of the dialog container"

And when worded like that, it's easy to see that's expected behavior :-)

I would suggest asking the Select2 developers to review the "z-index and stacking" section of http://wiki.jqueryui.com/w/page/12137737/Coding%20standards since there's a way for them to automatically have this work properly. It took us several years to figure this out, but so far it seems like a working solution for widgets.

Thanks for the insight. As dialogs have the ui-front class added automatically, this will work out of the box without overriding _allowInteraction() as soon as this coding standard is adopted, I see. I'll open an issue and/or submit a PR to Select2 this weekend, thanks again for the heads up. =]