Opened 5 years ago

Closed 5 years ago

#18286 closed defect (wontfix)

dijit/Destroyable exception if no method destroy/destroyRecursive/remove is available

Reported by: fbest Owned by: fbest
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.10.0
Keywords: Cc:
Blocked By: Blocking:

Description

b = new dijit.layout.BorderContainer();
b.own(new dojo.data.ObjectStore({labelAttribute:''}));
b.destroyRecursive()

TypeError: undefined is not a function
→ dijit.Destroyable.own()

maybe leaving it out then?

Change History (3)

comment:1 Changed 5 years ago by bill

Owner: set to fbest
Status: newpending

But doesn't the spec for own() say that the argument needs a destroy()/remove()/cancel() method?

comment:2 Changed 5 years ago by fbest

Status: pendingnew

not really: own() Defined by dijit/Destroyable Track specified handles and remove/destroy them when this instance is destroyed, unless they were already removed/destroyed manually.

Well, it would be nice if it is more robust. You can decide to set it as invalid as we removed the own(objectstore) call. But maybe there are more of these calls in our framework, we did a lot of own()ing since there are several memory leaks in IE when running dojo some hours without page reload.

comment:3 Changed 5 years ago by bill

Resolution: wontfix
Status: newclosed

I have no idea how it could be "more robust". dojo.data.ObjectStore? doesn't have a destroy()-like method, so it just gets garbage collected by the VM.

Note that the API documentation for Destroyable states that the handle needs a destroy method:

Call this.own(...) on list of handles (returned from dojo/aspect, dojo/on, dojo/Stateful::watch, or any class (including widgets) with a destroyRecursive() or destroy() method. Then call destroy() later to destroy this instance and release the resources.

The reference doc does need to be updated though, so I did that now in https://github.com/dojo/docs/commit/9b74bd6931fd8e3e705d3d6f8de03756ceddfb37.

Note: See TracTickets for help on using tickets.