Getting domNode null error dojox.mobile.ListItem.

[Ed Chatelain]

I have seen two problems working with dojox.mobile.ListItem? where the use of setTimeout to set something is getting an error. I am working from trunk.

I ran into both of these while working on a To Do app using dojox.app and dojox.mvc. I have a testcase I can provide to recreate the first problem. It is a modified dojox.mvc test, which uses class=mblVariableHeight, and is having a problem because of the call to SetTimeout? at line 199 in LineItem?.js To see the problem you can copy the test html file into the dojox/mvc/tests/mobile directory and run it from there, after the page is displayed click the "Swap Model 1" button to hit the error.

For the second problem (which is the more important one), I do not have a simple testcase, but you can recreate it from the To Do app here: ​https://github.com/cjolif/dojo-todo-app Once the ToDo? App is running, if you Click "Reminders", then Check item 1 and item 2. Then Select item 3 (the unchecked item). That will take you to the details for item 3, but it will also get an error "Cannot read property 'className' of null" because of a setTimeout call in _ItemBase at line 256.

[ben hockey]

#15064 is the same as the 2nd problem in this ticket. the null mentioned in "Cannot read property 'className' of null" is the domNode of the destroyed widget. there is a simple fix - the timeouts need to be cleared when the widget is destroyed. use _WidgetBase::defer() instead of setTimeout and this will be automatically managed for you. in addition to this one case, all other setTimeout calls should probably be changed to use _WidgetBase::defer() to avoid similar issues.

[ykami]

edurocher, I agree to use of defer() to solve the problems. Please make sure that you can recreate the very problems first, and then verify that use of defer() solves the problems.

[Eric Durocher]

Yes I can reproduce the first problem and using defer fixes it, but I can't reproduce the second problem: edchat can you help here? I am using the trunk + a zip of dojo-todo-app (taken this morning), I don't see the error (even checking and selecting quickly). I am pretty confident that changing both setTimeout calls is a good move anyways but I would like to reproduce the problem first...

[Eric Durocher]

I can reproduce both cases now. Attached patch that fixes these two cases.

(the patch fixes only the cases identified here, #15064 will be addressed later by replacing all setTimeout occurrences, this needs more work since the return value is sometimes used so the code needs refactoring in these cases)

[Eric Durocher]

Replace setTimeout by this.defer - Eric Durocher (IBM, CCLA)

[cjolif]

In [28525]:

fixes #15306. Fixes issue with ListItem?. Thanks Eric Durocher (IBM, CCLA). !strict.