Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#15306 closed defect (fixed)

Getting domNode null error

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:


I have seen two problems working with 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 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: 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)

test_mobile-list-single-sel-mvc-updated.html (7.0 KB) - added by Ed Chatelain 10 years ago.
15306.patch (913 bytes) - added by Eric Durocher 10 years ago.
Replace setTimeout by this.defer - Eric Durocher (IBM, CCLA)

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by Ed Chatelain

comment:1 Changed 10 years ago by Eric Durocher

Owner: changed from ykami to Eric Durocher
Status: newassigned

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by cjolif

Keywords: todoapp added

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

comment:5 in reply to:  4 ; Changed 10 years ago by 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...

comment:6 in reply to:  5 Changed 10 years ago by 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)

Changed 10 years ago by Eric Durocher

Attachment: 15306.patch added

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

comment:7 Changed 10 years ago by cjolif

Resolution: fixed
Status: assignedclosed

In [28525]:

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

comment:8 Changed 10 years ago by bill

Milestone: tbd1.8
Note: See TracTickets for help on using tickets.