Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#15953 closed defect (wontfix)

[regression] Calling widget.set after widget.destroy throws error in _WidgetBase.set

Reported by: Colin Snover Owned by: bill
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.7.3
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by Colin Snover)

_WidgetBase.set should be checking if this._destroyed and return immediately if true. It does not, so an error is thrown when it tries to access properties of this[defaultNode] which is null. This issue was introduced in Dojo 1.7.

Change History (5)

comment:1 Changed 7 years ago by Colin Snover

Description: modified (diff)

comment:2 Changed 7 years ago by bill

Resolution: wontfix
Status: newclosed

You aren't allowed to call set() on a destroyed widget and I doubt it ever "worked". Surely many custom setters, in addition to anything in attributeMap, will get an exception by trying to access this.domNode, this.focusNode, etc.

I'm sure there are many other widget methods that will also get exceptions if called after a widget is destroyed.

comment:3 Changed 7 years ago by Colin Snover

By that logic, I guess we shouldn’t check for this._destroyed in this.destroy either then because people shouldn’t call it more than once. By the way, how are consumers of widgets supposed to know that they can’t call set anymore without violating private access rules and checking the private variable widget._destroyed exactly?

Last edited 7 years ago by Colin Snover (previous) (diff)

comment:4 Changed 7 years ago by bill

That's true, I forget if destroy() was made idempotent by popular demand or to fix some other issue within dijit.

Users of widgets aren't supposed to know about the this._destoyed private variable, but it should be obvious from the documentation and name of the function that you can't do anything with widgets (or any object) after calling destroy().

comment:5 Changed 6 years ago by bill

FYI, in [29903] I checked in guard code for accessing this[defaultNode]. So I suppose that calling set("foo", "bar") after a widget is destroyed will no longer cause an error, even though it's not officially supported. Calling set(..., ...) on anything with a custom setter will still cause an error though.

Note: See TracTickets for help on using tickets.