A text widget that is added to a pane with the Add Widget action will echo the tab key to its contents at runtime, when it has focus. This does not follow the common user interface convention in which tab (and shift-tab) cycle through buttons, pull-downs, and other controls in order (or reverse order). This convention is followed by most of the InstallJammer widgets, but the text widget is a notable exception.
Rich-text editing controls generally don't follow this convention, since a tab character is much more likely to be embedded in the content of such a field. However, since the text widget is not a rich-text control, there is rarely much value (in my opinion) in the ability to include a typed tab character in its content.
I recommend that this behavior be changed, so that the default behavior is such that when a text widget has focus, typing the tab key will move focus to the next control, and shift-tab will move focus to the previous control. (There are some instances in which inclusion of a tab character in a text field is useful or even necessary; I recommend that these be handled by allowing the user to paste such text into the content of a text widget - and/or by echoing a tab character to the field contents when the the tab key is pressed with a modifier such as the ctrl key.