Consider a Java bean with a potentially _multi-line_ String field {{myField}} and associated {{config.jelly}} file {code:xml} <f:entry title="${%My field}" field="myField"> <f:expandableTextbox /> </f:entry> {code} If {{myField}} has a multi-line value (as decided by calling {{hudson.Functions.isMultiline(String)}}) when the web form is first loaded then everything works as expected - the {{Descriptor}}'s {{doCheck}} methods get called as expected (i.e. as documented). However, if the field value is either empty or is just a single-line value (i.e. when {{expandableTextbox.jelly}}'s {{test="${h.isMultiline(value)}"}} is not true) then {{<f:expandableTextbox />}} will never call the {{doCheck}} methods. That's a bug - it's not working as documented (or as expected). If a {{doCheck}} method is present, it should get called, regardless whether a field value is being rendered as a {{textarea}}, {{textbox}} or {{expandableTextbox}}.
Impact: This means that users entering data for the first time will not have their data validated. It also means that plugin developers can loose a few hours trying to figure out why one or more of their carefully-coded {{doCheck}} methods are being silently ignored most of the time... :(
Workaround: Developers could use {{<f:textarea />}} ... but that leads to a cluttered UI as it always uses a minimum height of 5 rows (as set by {{$\{h.determineRows(value)}}} which calls {{hudson.Functions.determineRows(String)}} which returns a minimum of 5 even for an empty string).
*TL;DR:* {{expandableTextbox}} should not be an exception to the general rule regarding form validation.
I just lost a couple of hours to this bug I've updated the description as best I can - it looks like the problem is (today) exactly as Kanstantsin described in the comments (from a few years ago) - but jelly code is not something I understand; I hope my clarification might help others who know jelly better than I do figure out a way forward...