Opened 5 years ago

Closed 5 years ago

#18187 closed defect (invalid)

focus problem with disposable-dialog&iframe

Reported by: gerhard presser Owned by: gerhard presser
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.10.0
Keywords: Cc:
Blocked By: Blocking:

Description

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.

Attachments (1)

focus.html (2.6 KB) - added by gerhard presser 5 years ago.

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by gerhard presser

Attachment: focus.html added

comment:1 Changed 5 years ago by bill

Owner: set to gerhard presser
Status: newpending

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.

comment:2 Changed 5 years ago by gerhard presser

Status: pendingnew

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

comment:3 Changed 5 years ago by 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 ;)

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by 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

comment:6 Changed 5 years ago by 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

comment:7 Changed 5 years ago by 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?

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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.

comment:10 Changed 5 years ago by bill

Status: newpending

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

comment:11 Changed 5 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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!

Note: See TracTickets for help on using tickets.