Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#9271 closed bug (notabug)

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?

Change History (5)

comment:1 Changed 10 years ago by Ult Combo

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

comment:2 Changed 10 years ago by Scott González

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.

comment:3 Changed 10 years ago by Ult Combo

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

comment:4 Changed 10 years ago by Scott González

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.

comment:5 Changed 10 years ago by Ult Combo

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

Note: See TracTickets for help on using tickets.