Opened 11 years ago
Closed 11 years ago
#10675 closed defect (worksforme)
Tree: setting path intermittently fails
Reported by: | Sébastien Le Ray | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | tbd |
Component: | Dijit | Version: | 1.4.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
I cannot find any other explaination than "randomly fails". Sometimes, a call to myTree.attr('path', something) fails and any subsequent call to myTree.attr('path', ...) with a path overlapping the one who failed also fails... After some tracking, it seems that the problem comes from the advance function for wich this._itemNodesMap is randomly undefined... It seems to means that it is called before the children update which is quite strange... _itemNodesMap being undefined, an exception is raised and the deferred of the corresponding _expandNode is tagged as faulty, thus callback are never called for it so subsequent programmatic expands do not work... It may be a bug in my custom store which does lazy loading (but during my tests I was able to reproduce this with dojox.data.FileStore?). Anyway, a way to fix it is attached. It is a really strange bug since as you can see, a second call to advance will succeed (otherwise we would get an infinite loop).
Attachments (1)
Change History (6)
Changed 11 years ago by
Attachment: | _setPathAttr.patch added |
---|
comment:1 Changed 11 years ago by
Component: | General → Dijit |
---|---|
Owner: | anonymous deleted |
Summary: | Setting dijit.Tree randomly fail → Tree: setting path intermittently fails |
Interesting, I don't suppose you can make a test case? I can take a look at the code and look for possible race conditions but a test case would help. I don't want to check in a workaround without knowing the root cause of the problem.
comment:2 Changed 11 years ago by
Yes I understand that... For now I haven't been able to reproduce this outside our application... It may be my store which is broken... I can email you the code if you think it may help.
comment:3 Changed 11 years ago by
Hi again... The supplied patch is highly buggy, I had other modifications to getsomething working... The only way I found to fix thing is to addErrback(advance) on the _expandNode deferred to allow things to work even if the deferred was first tagged as an error (or at least just test for this._itemNodesMap[identity] to avoid infinite loop)...
comment:4 Changed 11 years ago by
I don't see how _itemNodesMap could be null, as it's created in Tree.postMixInProperties(). Perhaps it's that _itemNodesMap[identity] is null, or that it doesn't contain any nodes?
Does this problem only happen right after page load? It looks like _loadDeferred may fire too early, after the children of the root node have loaded but before grandchildren etc. have finished loading.
comment:5 Changed 11 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I'm going to close this but please reopen if you can create a test case, thanks.
Patch agains 1.4.0-src that resolves the bug