Skip to main content

Search and Top Navigation

#9271 closed bug (notabug)

Opened May 03, 2013 03:57AM UTC

Closed May 03, 2013 12:22PM UTC

Last modified May 03, 2013 08:09PM UTC

Dialog: modal prevents focusing on absolutely positioned elements

Reported by: Ult Combo Owned by:
Priority: minor Milestone: none
Component: ui.dialog Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:

Dialog with modal:true prevents focusing on absolutely positioned elements.

>>> test case. The bug is not present in the editor screen, so please use the full page view as linked.

This was working fine as of jQuery UI 1.9.2, but now broken in 1.10.x - tested in Chrome and Firefox in W7 x64 Ultimate.

The use case, as shown in the test case, is using the magnificent Select2 plugin inside of my modal dialogs.

The issue seems to be related with

Some temporary workarounds I've found:

  • Remove the focusin.dialog listener from document when dialog opens (not perfect);
  • Override $.ui.dialog.prototype._focusTabbable - bin (loses some functionality though).

Of course, none of these are clean solutions. Is there any way to restore dialog <= 1.9.2 behavior so that absolutely positioned elements can be focused while having a modal dialog open?

Attachments (0)
Change History (5)

Changed May 03, 2013 04:55AM UTC by Ult Combo comment:1

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() {
        createOverlaybk.apply(this, arguments);

Changed May 03, 2013 12:22PM UTC by scottgonzalez comment:2

resolution: → notabug
status: newclosed

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.

Changed May 03, 2013 12:58PM UTC by Ult Combo comment:3

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")

Changed May 03, 2013 01:05PM UTC by scottgonzalez comment:4

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 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.

Changed May 03, 2013 08:09PM UTC by Ult Combo comment:5

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. =]