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

[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.

​http://jsfiddle.net/w8AqG/

[bill]

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.

[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?

[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().

[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.