#15306 closed defect (fixed)
Getting domNode null error dojox.mobile.ListItem.
Reported by: | Ed Chatelain | Owned by: | Eric Durocher |
---|---|---|---|
Priority: | undecided | Milestone: | 1.8 |
Component: | DojoX Mobile | Version: | 1.7.2 |
Keywords: | todoapp | Cc: | |
Blocked By: | Blocking: |
Description
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.
Attachments (2)
Change History (10)
Changed 9 years ago by
Attachment: | test_mobile-list-single-sel-mvc-updated.html added |
---|
comment:1 Changed 9 years ago by
Owner: | changed from ykami to Eric Durocher |
---|---|
Status: | new → assigned |
comment:2 Changed 9 years ago by
comment:3 Changed 9 years ago by
Keywords: | todoapp added |
---|
comment:4 follow-up: 5 Changed 9 years ago by
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.
comment:5 follow-up: 6 Changed 9 years ago by
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...
comment:6 Changed 9 years ago by
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)
Changed 9 years ago by
Attachment: | 15306.patch added |
---|
Replace setTimeout by this.defer - Eric Durocher (IBM, CCLA)
comment:8 Changed 9 years ago by
Milestone: | tbd → 1.8 |
---|
#15064 is the same as the 2nd problem in this ticket. the
null
mentioned in "Cannot read property 'className' of null" is thedomNode
of the destroyed widget. there is a simple fix - the timeouts need to be cleared when the widget is destroyed. use_WidgetBase::defer()
instead ofsetTimeout
and this will be automatically managed for you. in addition to this one case, all othersetTimeout
calls should probably be changed to use_WidgetBase::defer()
to avoid similar issues.