Opened 8 years ago
Closed 8 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)
Change History (12)
Changed 8 years ago by
Attachment: | focus.html added |
---|
comment:1 Changed 8 years ago by
Owner: | set to gerhard presser |
---|---|
Status: | new → pending |
comment:2 Changed 8 years ago by
Status: | pending → new |
---|
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 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
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 8 years ago by
Status: | new → pending |
---|
Also, make the test case without that infinite loop of the iframe including itself.
comment:11 Changed 8 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
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!
What is this line in your test doing?
It seems like an infinite loop because the main page is focus.html but then the iframe is also focus.html.