Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#7355 closed enhancement (wontfix)

Focusing should be disabled with an option [again]

Reported by: noldor Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.dialog Version: 1.8.11
Keywords: Cc:
Blocked by: Blocking:


Hi. Even if a similar request is denied here :, the situation must be re-considered.

Let me explain my problem with the situation i experienced.

I am using the jQuery UI in an IFramed social gadget application. I am showing information messages, such as "loading application", "initializing user settings", "rendering images" at the page load with the modal dialogs. Then i close those messages when application loading finishes.

Even if there are no form elements or input elements in the dialog box, still the box gets the focus. And if my iframed application is placed somewhere at the bottom of user's profile page, the parent page automatically scrolls down to bottom into my iframe.

And i can not manually get the scroll back to top, because my iframe page and the user's profile page are in different domains. I can not reach the parent window.

Please check my example at the following link and see how page scrolls down to bottom on the page load:

This focusing behavior should be disabled with an option.

Change History (3)

comment:1 Changed 12 years ago by noldor

If anyone else having the same problem, i found a temporary solution for myself, by removing the tabindex='-1' value from ".ui-dialog" element. I've noticed that jQuery automatically generates an "-1" value for the top level dialog box. But that -1 value is still triggering the focusing, even if you don't have any tabbable element in your modal dialog.

progDiv.dialog({ autoOpen: false, modal : true, resizable : false });



This prevents the window focusing if it does not have any input element inside.

And so on, the example link i referenced in my ticked is working just fine right now. You will not see the page scroll if you visit it.

But i think i've pointed the real problem about iframed contents.

Last edited 12 years ago by noldor (previous) (diff)

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

Resolution: wontfix
Status: newclosed

You shouldn't use a dialog if you want to display a non-interactive message that doesn't need to steal the user's attention.

comment:3 Changed 12 years ago by noldor

A library should not limit the developer on which purpose he/she is using the feature for. A library is always better with more options and with more compatibility with the situations.

I've explained a case that the developer needs a modal popup content, but doesn't need user's attention. An iframed web site always needs it. You should not steal user's attention if you're just a small iframed application in a profile page. But you're replying me saying that there is no such case which website may need a modal content with no user attention. I could simply use "alert();" method if i needed to steal user's attention for simple messages. But the situation here is displaying those messages with automatically opening and closing popups to show the current status.

I know i've been yakking a lot about this subject, but it is obvious from the other tickets that i am not the only one who wants such an option to disable dialog focusing.

I insist on the option is needed and must be re-considered.


Note: See TracTickets for help on using tickets.