focus problem with disposable-dialog&iframe

[gerhard presser]

I'm experiencing strange behavior in IE10/I11 (IE9 not tested). It seems to be causes by a combination of -) input fields on main-page -) open a dialog with a iframe & dijit-form-fields in it -) select one of those fields -) close & destroy the dialog -) ----I'm not able to select any of the input-fields on the main page

sometimes this situation resolves after some time - but most of the time I have to refresh the main-page

I cannot reproduce the problem, if I just hide the dialog (and not destroy it). I think there may be some references to a already deleted dom-node somewhere in dijit/Dialog or dijit/focus modules.

I couln'd reproduce this problem with dojo 1.9.3

I'll attach a testcase.

[bill]

What is this line in your test doing?

iframe.contentWindow.location = "focus.html";

It seems like an infinite loop because the main page is focus.html but then the iframe is also focus.html.

[gerhard presser]

yes - I just needed some content for the iframe ;-) if you keep on clicking the nested buttons you'll get lots of nested dialogs - but for the testcase, clicking the button once is enough ;-)

[gerhard presser]

because this issue is realy critical for our application I digged into some dijit-code and tracked the problem down to somewhere in dijit/focus and dijit/form/_FormWidgetMixin

In fact it seems to be some problem with form-widgets being destroyed immediately after being focused (e.g. OK button on a dialog, toolbar-button - click action causes item to be obsolete and therefore being destroyed)

A workaround I found out was to change dijit/focus.js[115] to

_this._onTouchNode(effectiveNode || evt.target/*,"mouse"*/);

I checked which code uses the 'by' parameter and came to _FormWidgetMixin the

_onFocus:function()

registers an pointerup-event to perform the actual focusing. If I remove this eventregistration or just remove the this.focus() call, it works even with the original focus.js

In all usecases that I was able to reproduce this behavior, an IFrame was involved. Do I have to register IFrames to dijit/focus?

any help or advice would be welcome ;)

[bill]

OK, understood about the iframe.contentWindow.location.

In all use cases that I was able to reproduce this behavior, an IFrame was involved. Do I have to register IFrames to dijit/focus?

Yes, there's a registerIframe() method that you need to call.

[gerhard presser]

unfortunately registering the Iframe in iframe.onLoad doesn't change anything.

the setup is like:

stack

tabcontainer

bordercontainer

toolbar

button

contentpane

iframe

<input>

I click the tabcontainer, then click the input-element in the iframe, then click the toolbar-button which causes the tabcontainer to be removed from the stack & destroyed

after that, not a single input-element is focusable/clickable any more - on the whole page.

sometimes it resolves after some clicking, or if I open e.g. a filteringselect's dropdown.

the app-code didn't change - it's a behavior we only see with dojo 1.10. we want to stick with this version, because of some other IE & focus related bugs which were fixed in 1.10

[gerhard presser]

this ​http://bugs.jqueryui.com/ticket/9122 and ​http://bugs.jquery.com/ticket/12319 describe similar/same problems.

I tried to move the Iframe to the body and destroy it afterwards - seems to work. Does anybody have some info about this weird behavior? f... IE

[bill]

I click the tabcontainer, then click the input-element in the iframe, then click the toolbar-button which causes the tabcontainer to be removed from the stack & destroyed

OK, I really don't understand what's going on at all. Who is destroying the TabContainer?? And what about the Dialog?

[gerhard presser]

the toolbar-button is e.g. a 'save and close' - it performs an ajax-call and then destroys the tab-container.

concerning the dialog - since I found the usecase described above (tabcontainer), it seems to have nothing to do with the dialog itself, but with the nested Iframe - it's just another usecase.

but I cannot change the issue's subject.

[bill]

Oh, so the tab-container being destroyed is expected (correct) behavior.

It sounds like the problem you are having is with the DialogUnderlay? remaining on the page. Yet you just said that this bug has nothing to do with a Dialog? If that's really true, please attach another test case showing the problem without a dialog.

[bill]

Also, make the test case without that infinite loop of the iframe including itself.

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!