Opened 10 years ago

Closed 9 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)

_setPathAttr.patch (782 bytes) - added by Sébastien Le Ray 10 years ago.
Patch agains 1.4.0-src that resolves the bug

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by Sébastien Le Ray

Attachment: _setPathAttr.patch added

Patch agains 1.4.0-src that resolves the bug

comment:1 Changed 10 years ago by bill

Component: GeneralDijit
Owner: anonymous deleted
Summary: Setting dijit.Tree randomly failTree: 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 10 years ago by Sébastien Le Ray

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 10 years ago by Sébastien Le Ray

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 10 years ago by bill

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 9 years ago by bill

Resolution: worksforme
Status: newclosed

I'm going to close this but please reopen if you can create a test case, thanks.

Note: See TracTickets for help on using tickets.