#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 )
_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 8 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 8 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 Changed 8 years ago by
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?
comment:4 Changed 8 years ago by
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 8 years ago by
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.
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.